Sage 50 Accounts UK — on-site agent

The GoRoute Sage 50 Agent is a small Windows program that runs on the PC that holds (or reaches) your Sage 50 company data. Sales invoices you post in Sage leave over Peppol, or — when the customer is not on Peppol — as a ZUGFeRD PDF that GoRoute emails to them. Supplier invoices that arrive over Peppol come back as a Sage import file, which the bookkeeper brings in with File ▸ Import. Nothing changes about how anyone raises an invoice in Sage, and nothing is installed inside Sage: no add-in, no Sage Developer Programme membership, no Sage Data Objects, and no Enable 3rd Party Integration licence.

This connector is in pilot

The agent is new. It is built against Sage 50 Accounts UK v34 and its own test suite runs against a reconstructed Sage dataset, but it has not yet been run against a live Sage 50 installation, and a handful of Sage behaviours can only be confirmed on a real v34 installation — the ODBC driver's exact name and whether it is 32-bit, some Sage column names, and whether the audit-trail import template on v34 really carries Extra Reference. Those are listed under What is still being confirmed and are settled during your installation, on your own machine, before anything real is sent. Until the agent is generally available, the supported no-agent route is a Report Designer export uploaded to the GoRoute portal.

Why an agent and not a cloud connection

Sage 50 Accounts UK is a desktop product with its company data in a folder on a PC or a file server. It has no REST API — the "Sage 50 API" belongs to the North American product, and Sage Business Cloud is a different product altogether. There is no route into Sage 50 from the cloud at all, so the only honest design is a program on the machine that can already see the data. The agent makes outbound HTTPS calls only and opens no port on any network interface; its own small status window is served on 127.0.0.1 and is reachable from that PC only.

What you need

Sage	Sage 50 Accounts UK. Built against v34, which is the version the pilot confirms; v27 and later are expected to work, and neither expectation has been tested on a live installation yet
How you raise sales invoices	In Sage's Invoicing module. A company that types its sales invoices straight in at Customers ▸ Batch invoice is not covered — the agent cannot see those invoices at all. Check this before anything else; it is the one prerequisite that can rule the connector out entirely, and it is explained under Limits worth knowing
Windows	Windows 10 or 11, signed in as the person who normally uses Sage on that PC
The date format on that PC	That user's short date must be day first — dd/MM/yyyy, or dd.MM.yyyy on a German machine. Sage reads the dates in the supplier-invoice file in the signed-in user's own format, so a month-first setting would post 12/10/2026 as 10 December and put the invoice in the wrong VAT period with no error anywhere. The readiness report checks it and stops you
The Sage ODBC driver	Ships with Sage 50 and is enabled from within Sage. The agent only ever reads through it — the driver is read-only and cannot change your data
A Sage user for the agent	A Sage 50 user called GOROUTE with read-only rights. The ODBC connection signs in to Sage as a Sage user, and it should be one created for this rather than manager: the agent only ever reads, so the account it signs in with should not be able to do anything else. Its password is held in the data source on that PC. Created during the remote install
Which PC	One PC, the one that holds the company data folder (…\ACCDATA) or has it mapped. A data folder on a server is fine; the agent still runs on one workstation
A GoRoute account	And an API key with read, write and send permission, from the GoRoute dashboard (API Keys)
Matching VAT numbers	The VAT number on the Sage company and the one on your GoRoute organisation must be the same number. If they differ, something is set up wrong and the readiness report stops you — see the readiness report
Network	Outbound HTTPS to GoRoute. No inbound port, no VPN, no fixed IP

Sage Data Objects (SDO) is not required and must not be switched on for this. If somebody suggests enabling Tools ▸ Activation ▸ Enable 3rd Party Integration, that is for a different kind of integration; the agent does not use it and does not benefit from it.

Why one PC, and not a service

The API key is protected with Windows DPAPI on first run. DPAPI ties the protected key to the Windows user profile it was protected under, which is why the agent runs as the signed-in user with a tray icon rather than as a Windows service: a service account could not read it. The practical consequences:

• The agent polls while that user is signed in to Windows. Sage itself does not need to be open.
• Move to a new PC, or a new Windows profile on the same PC, and the stored key cannot be read there. Install the agent again on the new profile and paste the API key once more; everything else, including the record of what has already been sent, can be carried over or simply rebuilt by the reconciliation pass.
• Two agents must not watch the same company. If you are migrating, uninstall the old one first.

Installing

The installation is done with a GoRoute engineer, over a remote session (AnyDesk) on the PC that will run the agent. Allow about two hours. You do not need to prepare anything beyond the items under What you need and knowing which PC holds the company data; the engineer drives the wizard, and the two of you go through the readiness report together.

There is no training course and no separate manual: this page is the documentation, for the person who uses Sage every day as much as for whoever installs it. Everything below can be done again from this text alone — a reinstall, a new PC, a new member of staff — and the sections after it are written to be read cold, months later, by somebody who was not on the call.

The installer is a signed Windows wizard. It is run as the user who will be signed in to that PC day to day.

1. API address and API key. The address is filled in for you. The key is the one from the GoRoute dashboard under API Keys, with read, write and send permission; paste it once. From the first run onwards it is held DPAPI-protected and is never shown again, so keep your own copy wherever you keep credentials.
2. Companies found. The wizard lists the Sage companies it can see and you tick the ones to connect. Only ticked companies are ever read. On a Sage installation holding a UK company and, say, a German branch, ticking the German company means the UK company is never touched. Tick nothing you are not going to e-invoice.
3. A Sage user, and the data source (DSN). In Sage's own user settings (Settings ▸ Access Rights) a user called GOROUTE is created with read-only rights, and the wizard then creates one ODBC data source per ticked company — pointing at that company's data folder and signing in as that user. One company, one DSN; nothing to decide. Using a read-only user rather than manager is deliberate rather than cautious: the agent never writes to Sage, so the account it signs in with should not be able to, and that password is sitting in a data source on a workstation. Keep the GOROUTE user when you tidy up Sage users — deleting it stops the agent reading, and the agent will say so.
4. Tax codes. The wizard offers a starting tax-code table, and you check it against the company's real codes. Open Sage alongside it at Settings ▸ Configuration ▸ Tax Codes, and for every code that appears on your sales invoices confirm that the rate matches and that the meaning is right — standard, zero-rated, exempt, intra-community, reverse charge, outside scope. Tax codes explains each of those and shows the defaults. This is the step that most repays care, because a code that is mapped to the wrong meaning produces invoices that are accepted and wrong, which is worse than ones that are refused.
5. Readiness report. The wizard finishes by running a read-only pass over the company and showing the report described in the next section. Nothing has been sent at this point, and nothing is sent while you work through it.

Settings are written to agent.yaml in the agent's own data folder, and the agent starts with Windows from then on. The readiness report is always available again from the agent's own window, and at http://127.0.0.1:8731/readiness.html in a browser on that PC.

Before the engineer leaves the call, two things are worth doing while somebody is watching: send one real invoice to a customer who is on Peppol and one to a customer who is not, and agree who in the business will look at the agent window each day.

The readiness report

The report is read-only: it reads your Sage data and your GoRoute settings and tells you what would stop an invoice going out. Working through it is the main piece of preparation there is, and it is worth running again a few weeks after go-live and whenever you take on a batch of new customers.

Each finding says where it is fixed. Most are records in Sage, but one is in the GoRoute portal and one is in the agent's own settings, and the report names which — looking for a field in the wrong product is the most expensive mistake available here.

Blocking: these invoices cannot be sent at all

Sales invoices are being batch-entered rather than raised in the Invoicing module. This is the first thing the report looks at, because it is the only finding that can mean the connector does not suit your company at all: an invoice typed in at Customers ▸ Batch invoice keeps no lines, so the agent cannot see it and never will. It is not a record to correct — it is a question about how your company works, and Limits worth knowing sets out the two possible answers. Deal with this one before spending time on any of the others.

The VAT number on the Sage company does not match the one on your GoRoute organisation. Two different numbers mean somebody is about to invoice under the wrong identity. Note which way the error would fall: the agent takes the seller's details from the GoRoute profile, so invoices would go out carrying GoRoute's number whatever Sage says — the number nobody checked. Establish which of the two is correct before anything is sent, and do not simply edit one to match the other. One of them is wrong, and which one depends on which legal entity is actually making these sales; that is a question for whoever owns the VAT registration, not a data-entry fix. On a Sage installation holding more than one company this finding most often means the agent has been pointed at the wrong company, which is a far better thing to discover here than in a customer's inbox.

A customer with no Peppol identifier and no usable VAT number. Every e-invoice has to be addressed to the buyer, and if there is nothing to address it to, GoRoute refuses the document. It does not quietly send it some other way, and that includes the e-mail route: an emailed ZUGFeRD invoice still has to name the buyer, so a missing identifier is not something e-mail rescues. Open Customers, find the record, and either put the customer's Peppol identifier in Analysis 1 (see The buyer's Peppol identifier) or enter their VAT registration number. If the customer is a consumer, or a business that genuinely has neither, that customer cannot be e-invoiced at all: keep them on your normal paper or PDF routine and leave them out of this.

A customer in Sweden, Finland, Denmark, Norway, Switzerland, Singapore or Japan with nothing in Analysis 1. For these seven countries a VAT number is not enough, so Analysis 1 is required rather than optional — the reason for each is in Seven countries where Analysis 1 is required. The report names every such customer individually, because without Analysis 1 each of their invoices is refused. This is the finding most likely to be a surprise, so check it first if you sell into Scandinavia, Switzerland or Asia.

A customer with no country. The country on the customer's address is what decides which identifier scheme the invoice is addressed under, and which country's rules it is checked against. A blank country leaves the invoice unaddressable even when the VAT number is there. Set the Country on the customer's address in Customers.

Your own telephone number or e-mail address is missing. German Peppol rules DE-R-006 and DE-R-007 require the seller's contact telephone number and contact e-mail address on an invoice where both seller and buyer are in Germany, and both are hard failures — the invoice is refused, not warned about. Fix this in the GoRoute portal, not in Sage: open Settings ▸ Company Profile and fill in the telephone number and e-mail address. The agent takes the seller's own details — VAT number, address, contact and bank account — from that profile and never from your Sage company record, so changing it in Sage has no effect at all. Fill both in whatever country you sell from; they cost nothing and other countries' rules ask for them too.

A tax code with no mapping. A Sage tax code the agent has not been told the meaning of parks every invoice that uses it, naming the code. Fix it in the agent's own window, under Settings: add the code with its category and rate from the table in Tax codes. The agent will never guess, and this is deliberate — inventing 19 % on what is actually an intra-EU supply would file a wrong VAT return, so stopping and asking is the only safe behaviour.

A company whose column probe failed. At start-up the agent checks that every Sage field it reads is actually present. If one is missing it names the exact table and column and refuses to poll that company rather than send half an invoice. Nothing in Sage will fix this: send the message to GoRoute support — see Troubleshooting.

Worth fixing, but nothing is blocked

A customer outside those seven countries with a VAT number and nothing in Analysis 1. Not an error. The agent derives the Peppol identifier from the VAT number and the country, which is right for most European business customers. The report lists them only so you can spot the ones that receive under a different identifier — a German public-sector buyer with a Leitweg-ID, for instance — and put that in Analysis 1 instead.

A customer with no e-mail address. Only matters for customers who are not on the Peppol network: those are delivered as a ZUGFeRD PDF that GoRoute emails, and with no address there is nowhere to send it. Fill in the customer's E-mail field in Customers. A customer who is on Peppol does not need one.

A supplier with no VAT number. The agent matches an arriving supplier invoice to a record in Suppliers on the VAT number first and then on an exact name match, so a supplier without one usually lands in Needs supplier for somebody to pair by hand. Add the VAT number in Suppliers and the agent matches it on its next pass. Nothing is lost in the meantime — the invoice waits rather than being dropped — but it is a queue somebody has to keep clearing, so it is worth doing before go-live rather than after.

Tax codes

Sage 50 tax codes are user-defined per company. T1 is 20 % in one company and 19 % in another; a company can define T20 for reverse charge or not define it at all. So the table below is the set of defaults the installer offers for a German company, and it is confirmed against the company's own Settings ▸ Configuration ▸ Tax Codes at install. Nothing here is assumed.

Sage tax code	Treated as	Rate	Meaning on the e-invoice
T1	S — standard rate	19 %	Standard-rated supply
T5	S — standard rate	7 %	Reduced-rated supply
T0	Z — zero rated	0 %	Zero-rated supply
T2	E — exempt	0 %	Exempt supply
T4	K — intra-community	0 %	Intra-community supply, reason VATEX-EU-IC
T9	O — outside scope	0 %	Outside the scope of VAT
T20	AE — reverse charge	0 %	VAT reverse charge
export code	G — export	0 %	Export outside the EU, reason VATEX-EU-G

The mapping runs the other way too, for incoming supplier invoices: a 19 % line on a Peppol invoice becomes T1 in the import file. If you later add or redefine a tax code in Sage, add it to the agent's table in the same sitting — the readiness report will otherwise find it the hard way, as parked invoices.

The buyer's Peppol identifier: Analysis 1

Every e-invoice is addressed to the buyer's Peppol identifier. A customer the agent cannot find one for cannot be invoiced at all — GoRoute refuses the document rather than sending it some other way, and e-mail is not an exception, because an emailed ZUGFeRD invoice has to name the buyer too. So this field decides which of your customers the agent can serve.

Sage customer records carry three free-text Analysis fields. The agent reads Analysis 1 as the place to state a Peppol identifier explicitly, written as scheme:identifier — four digits, a colon, then the identifier, no spaces:

9930:DE274991849

Leave Analysis 1 empty and the agent derives the identifier from the customer's VAT registration number and the country on their address. That works for most European business customers, and for them Analysis 1 is genuinely optional.

Seven countries where Analysis 1 is required

For customers in these countries a VAT number cannot be turned into a Peppol identifier at all, so Analysis 1 must be filled in or the invoice is refused:

Customer's country	Why the VAT number is not enough
Sweden	Its VAT-number scheme has been removed from the Peppol identifier list
Denmark	Its VAT-number scheme has been removed from the list
Norway	Its VAT-number scheme is deprecated
Finland	Finland's Peppol scheme is the OVT code, which is not the VAT number
Switzerland	Peppol does have a Swiss VAT scheme, but GoRoute does not yet derive an identifier from a Swiss VAT number. A change to add it is in progress; until it ships, Analysis 1 is required
Singapore	No VAT-number scheme; Singapore addresses businesses another way
Japan	No VAT-number scheme

Six of the seven are what the Peppol identifier list itself says, not a GoRoute restriction, and no amount of correcting the VAT number in Sage will change the outcome; Switzerland is the exception — there the scheme exists and GoRoute has yet to use it. Either way the answer today is the same: put the identifier in Analysis 1. The readiness report names every affected customer, and it is a blocking finding.

What to put there. Ask the customer for their Peppol address, or their provider for it: a business that receives e-invoices knows what it is, and it is usually printed on their own invoices or in their supplier-onboarding pack. It arrives already in scheme:identifier form (Swedish organisations are usually addressed under scheme 0007 and Norwegian ones under 0192, both with the organisation number rather than the VAT number), and you type it in exactly as given, scheme and all. If a customer in one of these countries cannot tell you their Peppol address, they are probably not on the network: leave them on your ordinary invoicing routine rather than guessing an identifier, because a guessed address either fails or — worse — delivers your invoice to somebody else.

When to fill it in anywhere else

Fill in Analysis 1 for any customer who receives under something other than their VAT number:

• A German public-sector buyer, which receives under its Leitweg-ID.
• A customer whose provider registered them under a company-registration number rather than a VAT number.
• Any customer who simply tells you their Peppol address — it is always safer than a derivation.

What is in Analysis 1 always wins, so it is also how you correct a customer whose derived address turned out to be wrong.

Day to day: sales invoices out

Nothing changes in how invoices are raised. Enter the invoice under Invoicing as you always have and update the ledgers (post it) as you always have. The agent only ever looks at posted invoices, so drafts and unposted invoices are invisible to it — and so are invoices typed in at Customers ▸ Batch invoice, which is the one real exception to "nothing changes" and is explained under Limits worth knowing.

Within about five minutes:

1. The agent sees the newly posted invoice and builds the e-invoice from it — header, customer, lines and tax codes from Sage, and the seller's own details (VAT number, address, bank account) from your GoRoute company profile, so there is nothing to keep in step by hand.
2. It is checked against your country's official rules before anything is sent.
3. It goes out: over Peppol when the customer is registered on the network, otherwise as a ZUGFeRD PDF that GoRoute emails them. Either way the customer needs a Peppol identifier — a customer without one is parked rather than sent.
4. The agent window moves the invoice from Queued to Sent.

Credit notes take exactly the same path, citing the invoice they credit.

If something is wrong, the invoice is Parked with the reason in plain words — the customer's VAT number is missing, a tax code is not mapped, an amount does not add up — quoting GoRoute's own validation messages rather than a code. Fix the record in Sage and the agent picks up the correction and retries by itself; there is also a Retry button if you want it to go now. A parked invoice never blocks the invoices behind it.

If the PC is off, or the internet is down, invoices sit safely in the agent's own queue on disk and go out when it comes back. The agent raises an alert when the oldest unsent invoice has been waiting more than eighteen hours — a PC that is switched off cannot tell you it is switched off, so what is watched is the size and age of the backlog rather than whether the agent is "online".

Once a day the agent re-reads every invoice posted since go-live and queues anything that has no record of being sent. That sweep, not the running total, is what makes completeness checkable: a missed invoice is found the next day rather than never.

Nobody uploads a CSV, maps columns, or signs in to the portal for routine work. The portal is for history, evidence and oversight.

Day to day: supplier invoices in

Supplier invoices that arrive for you over Peppol are turned into a Sage import file. The agent window says, for example, 3 supplier invoices ready.

1. Take a backup, as you would before any Sage import.
2. Close what you are doing in Sage. The import asks "This closes all other open windows … continue?" before it starts, and it is worth being the only person in the company while it runs.
3. Open File ▸ Import and choose Audit Trail Transactions. On the Data Source step, browse to the day's file first — C:\ProgramData\GoRoute\Sage50\Inbox\<date>\, one folder per day, named by date — and tick First row contains headings afterwards. That order matters: the tick box clears itself when you choose a file, and ticking it while a file is already selected clears the file. With the box ticked Sage matches every column by its name on the first line of the file, so there is nothing to map by hand and no template to load.
4. Sage shows you what it is about to post before it posts it, and lists anything it did not take at the end. Read both.
5. The supplier invoice PDFs sit in the same folder, next to the file, for your own filing.

Each invoice is written as purchase-invoice (PI) or purchase-credit (PC) rows — one row per VAT rate, not one per invoice line, because the Sage audit trail is a ledger rather than a copy of the invoice. The supplier is matched on VAT number and then on an exact name match; an invoice from a supplier not in Suppliers appears under Needs supplier, and once you have created that supplier record in Sage the agent matches it on its next pass without being told.

Every row carries the GoRoute document number in Extra Reference. After you import, the agent's next read finds the posted transaction by that reference and reports it back, so the GoRoute portal shows the invoice as posted in Sage with nobody telling it.

Import each day's file once

Sage will import the same file a second time without warning you. It does not refuse, it does not ask: the rows go in again and the supplier balance doubles. Nothing in Sage will tell you.

The agent is what catches it — on its next read it sees more transactions under one document than it wrote rows for, and flags the invoice in the portal with the Sage transaction numbers so you can delete the duplicate. But it finds this out after the fact, so the habit that matters is: import a day's file once, and move on to the next day's folder.

The import click is deliberately manual. Sage 50 has no command line for Import, and driving the Sage window with automation software breaks on every Sage update and only works while somebody is signed in. For a typical volume of supplier invoices a month that is not a trade worth making; three clicks a day that work every time beat automation that fails silently. Fully hands-off posting needs Sage's paid developer tooling, which is a separate commercial decision and is not part of this product.

Customers who are not on Peppol

Most customers of a typical Sage 50 company are not on the Peppol network, and the mandates still apply. For those, GoRoute produces a ZUGFeRD PDF — a PDF that is also a machine-readable e-invoice — and emails it to the address on the Sage customer record, from GoRoute's own verified sender with your company as the reply-to address.

The e-mail route still needs the customer's Peppol identifier. This catches people out, so it is worth being plain about: the e-invoice inside that PDF has to name the buyer in the same way a Peppol one does, so a customer with no identifier and no derivable VAT number is refused on this route exactly as on the other. E-mail is a different delivery channel, not a lower standard of document. See Analysis 1.

Two choices are made at install, per company:

• auto — GoRoute sends the email as soon as the document is issued. Recommended; it is one fewer thing for anybody to remember.
• queue — the invoice waits in the agent window until somebody clicks Send email. Choose this if you want a human eye on every outgoing document for the first few weeks.

That document is now the invoice. Once a customer is served this way, stop emailing Sage's own invoice PDF to them for that company — otherwise they receive two documents for one sale and will ask which one to pay. In practice that means checking two habits: whoever runs the invoice print or e-mail job in Sage leaves the e-invoiced customers out of it, and any customer set up to be emailed automatically from Sage is taken off that run. Go through it once, company by company, on the install call, and again if somebody later adds a new automatic e-mail run.

Limits worth knowing

Read the first one before you plan anything else. It is the only limit on this list that can mean the connector does not cover your company at all.

Invoices you batch-enter are invisible to the agent

Sage 50 gives you two ways to get a sales invoice onto the ledger, and the agent can only see one of them.

• Raised in the Invoicing module — you enter the invoice under Invoicing, print or email it, then Update ledgers. Sage keeps the invoice itself, with its lines, prices and tax codes. This is what the agent reads.
• Typed in at Customers ▸ Batch invoice — Sage posts the totals straight to the audit trail and keeps no invoice record and no lines at all. There is nothing for the agent to read, and nothing an e-invoice could be built from: an e-invoice needs the lines, and a batch entry never had any.

The agent does not fail on a batch-entered invoice — it never sees it, and that is worse than failing. Nothing is parked, nothing turns red, and no count goes up; the agent reports a quiet, healthy day. Reading batch-entered invoices is not built, and rebuilding an invoice from audit trail totals is not a setting somebody can switch on for you.

So: if your company enters sales invoices in batch, this connector does not cover you yet. Raise it before the install rather than after, because there are only two answers and both take a decision — move that invoicing into the Invoicing module, or wait for a version of the agent that can work from the audit trail. The readiness report checks this at install and flags it, so the question is settled against your own Sage data rather than from anybody's memory of how the invoicing gets done.

The rest

• Only invoices that arrive over Peppol reach the agent. A ZUGFeRD or XRechnung that a supplier emails you stays in your mailbox; the agent never sees it and it is not in the import file. Mailbox ingest — a dedicated inbound address and a parser on the platform — is a separate platform feature, not part of this agent.
• One PC per company. The agent is not clustered and two agents must not watch the same company.
• Only ticked companies. A company you did not tick at install is not read at all, which is the point on a multi-company Sage installation.
• Unposted invoices are invisible. An invoice that has not been updated to the ledgers does not exist as far as the agent is concerned.
• The import click is manual (see above). Sage closes your other windows to do it, so run it when nobody else is working in the company.
• A customer with no Peppol identifier cannot be invoiced through the agent at all, and e-mail is not a way round it — see the Analysis 1 section.
• Japan is email only. GoRoute does not produce the Japanese Peppol specification, so Japanese customers are served by the emailed hybrid PDF — and they still need an identifier in Analysis 1, because a Japanese VAT number cannot be derived into one.

Troubleshooting

We posted invoices today and the agent shows nothing at all. Check first how those invoices were entered. An invoice typed in at Customers ▸ Batch invoice is invisible to the agent — it is not queued, not parked and not counted, so an empty agent window is exactly what you would see — and that is a limit rather than a fault (why). If they were raised under Invoicing, check next that they were posted (Update ledgers), that their company is one of the ticked ones, and that the agent is running on the PC you think it is; the agent window can then be asked to run a pass immediately rather than waiting for the next one.

"The agent refuses to poll <company>: <table>.<column> is missing." The start-up probe found a Sage field the agent reads that is not present in that company's data. It is deliberate that it stops rather than sends something incomplete. Send the message to whoever installed the agent: the column list is checked against a real v34 schema and corrected in the agent, not worked around in Sage.

The agent cannot connect to Sage at all / "data source not found". Four causes, in the order worth checking: the ODBC driver is no longer enabled in Sage; the GOROUTE Sage user has been deleted, renamed, had its password changed or had its rights removed in Settings ▸ Access Rights, which happens when somebody tidies up Sage users and does not recognise the name; the data source the installer created no longer points at the company folder (a moved or renamed ACCDATA path does this); or the driver and the agent are different bitnesses. On the second, re-create the user read-only under the same name and the agent picks up where it left off — no invoice is lost, because nothing is sent until it can read. On the last, a 32-bit-only ODBC driver needs the 32-bit build of the agent — a 64-bit program cannot load a 32-bit driver, whatever the data source says. Both builds exist; ask GoRoute support for the 32-bit installer if the driver on your machine is 32-bit.

Everything stopped working after a Windows profile change, or on a new PC. The API key is DPAPI-protected and bound to the Windows profile it was protected under, so it cannot be read from another profile. Install the agent on the new profile and paste the API key again.

An invoice is Parked. The reason is GoRoute's own validation message, shown verbatim. The common ones are all readiness-report findings:

What the message is about	Where you fix it
The buyer has no Peppol identifier, or none can be derived	Analysis 1 on the customer in Sage — and if the customer is in one of the seven countries, Analysis 1 is the only fix
The buyer has no country	The customer's address in Sage
A tax code has no mapping	The agent's own window, under Settings
The seller's telephone number or e-mail address is missing	The GoRoute portal, Settings ▸ Company Profile — not Sage

Fix it, then wait for the next pass or press Retry. A parked invoice never blocks the ones behind it, and nothing is lost while it waits.

An invoice says it was sent but the customer has not got it. Check the agent window for the delivery channel. Peppol means it reached the customer's provider. Email on a company set to queue means it is waiting for a click. Email on a company set to auto and still not arrived usually means the address on the Sage customer record is wrong — the agent reports the email failure rather than hiding it.

A supplier invoice is under Needs supplier. There is no matching record in Suppliers. Create the supplier in Sage once, with its VAT number, and the agent re-matches on its next pass.

"HTTP 401" in the log. The API key is wrong, revoked, or lacks send permission. Issue a new key in the GoRoute dashboard and paste it into the agent's settings.

Where the log is. The agent window names its own data folder, which is where the log and the queue are kept; the supplier-invoice files are under C:\ProgramData\GoRoute\Sage50\Inbox\. Attach the log to any support request, along with the invoice number the problem is about.

Support: admin@goroute.ai.

Updating and uninstalling

Updating is manual for this version. There is no self-update: GoRoute sends you a new signed installer, you run it on the same PC as the same user, and it replaces the program. Your settings, tax-code table, queue and record of what has been sent are untouched. Nothing is re-sent, because every document carries a key derived from the company and the invoice number — a replay is recognised and ignored on both sides.

Uninstalling removes the program and stops it starting with Windows. It leaves behind, on purpose, the agent's data folder: agent.yaml (your settings and tax-code table), the queue of what has and has not been sent, and the supplier-invoice import files and PDFs already written to the Inbox folders — those are your records. Delete that folder by hand if you want the machine genuinely clean. The ODBC data sources the installer created are left in place; nothing reads them once the agent is gone, and they are read-only in any case. The GOROUTE Sage user is left in place too — delete it in Settings ▸ Access Rights if you are removing the agent for good, since an unused read-only login is tidier gone than kept. Uninstalling the agent does not change anything inside your Sage data: no records, layouts or settings in the company data are touched at any point, by install, update or removal.

What is still being confirmed

Most of this section used to be a list of things nobody outside Sage's paid developer programme could know. They were measured on a real Sage 50 Accounts UK v34.1 on 28 October 2026 — both halves: reading the company over ODBC, and putting a file through File ▸ Import by hand. What that settled is already in the behaviour described above, including two things it changed: how a service invoice is told apart from a credit note, and how the day's file is imported.

Three things are still open, and none of them stops the connector working:

1. A day's file that holds two VAT rates posts as two audit-trail transactions, and that is what the duplicate check counts on. Sage also offers a grouped import that would post them as one transaction with two splits; which way your version takes the file is confirmed on yours, and the check is written so that it notices either way rather than guessing.
2. Whether Exchange Rate imports. It does not matter yet: an invoice in any currency other than your company's own is left for you to enter by hand, because a supplier's invoice does not carry the rate you would post it at.
3. The single-user rule for File ▸ Import when the company data folder is shared from a server — whether Sage insists on being the only session, or merely closes your other windows. Either way the advice is the same: run the import when nobody else is in the company.

And one thing that is about your company rather than about Sage: which VAT codes, currency and customer details you actually use, which is what the readiness report and the tax-code step of the install are for.

For the implementing engineer

The agent's architecture, module boundaries, interfaces and build are in the repository, not on this site:

• sage50-agent/README.md — the contract the code is built to: layout and import rules, the Sage reader interface, the mapping to GoRoute's canonical invoice, the tax-code and participant-scheme tables, the outbox state machine, the sender's retry and back-off behaviour, the inbound puller and import-file writer, the loopback status API, and the shape of agent.yaml. Its §6 is what the two v34.1 measurements settled and what they did not, written for somebody with a Windows box in front of them.
• sage50-agent/docs/WINDOWS-DEV-SETUP.md — standing up the development machine: the Windows VM, a Sage 50 Accounts UK v34 installation and dataset, dumping the real ODBC schema, and confirming the driver's bitness.
• docs/SAGE50-AGENT-PLAN-2026-10-26.md — the design record: the integration surfaces that were considered, why Sage Data Objects and the Developer Programme were rejected, why the import click stays manual, and what the platform side owes.

The test suite runs with no Sage, no ODBC, no Windows and no network — the Sage reads are backed by a SQLite fixture behind the same interface — so mapping and tax-code work can be done and reviewed on any machine. What cannot be done on any machine is anything in the list above; that needs the real thing, and until it has had it, nothing on this page should be repeated to a customer as settled.