Stop retyping invoices into your accounting system

By the time a delivery is signed for, your transport system already holds nearly everything an invoice needs. It knows who ordered the job and which company is billed, what rate was agreed, which surcharges applied, what the VAT treatment should be, and on which day the goods actually moved. Then, in a great many carriers, somebody opens the accounting system and types all of it in a second time.

That second pass is the part worth attacking. It is not skilled work — it is transcription — and it sits directly between a delivered load and an invoice sent. In a small office it is an afternoon a week; in a busier one it is a role. Either way it happens after the money has been earned, which is why invoicing lag is so often measured in weeks rather than days. (We have written separately about invoicing on the delivery day.)

The errors are the quieter cost. Nobody keys several hundred invoice lines a month without transposing a figure or picking the customer one row above the right one. Those mistakes surface late — at the reminder, at the reconciliation, or in a customer’s complaint — and each one costs more to unpick than it would have cost to avoid.

What actually crosses the wire

“Accounting integration” is a broad phrase covering some quite different things. Ask a vendor which of these they mean:

• Customers. Your organisations, pushed to the ledger as customer records: name, address, organisation number, payment terms, VAT registration. This is the part people forget to ask about, and it decides whether an invoice can post at all — an invoice for a customer the ledger has never heard of is rejected, not queued.
• Invoices, with their lines. The header — customer, invoice date, due date, currency, number — and each line: description, quantity, unit price, VAT rate, and the article or account it books against.
• Article and account codings. The bridge between what you sell and how it is booked. A line reading Fuel surcharge, 480 kr has to become an entry against a specific article or revenue account with a specific VAT treatment. That decision should be made once, by someone who knows your chart of accounts, rather than several hundred times by whoever is invoicing that week.
• What comes back. Payment status is the useful return trip. An invoice marked paid in the ledger can close the job in the transport system, so your overdue list is the real one rather than a copy of a copy.

Notably absent from that list: your bookkeeping. An integration moves documents. It does not do the accounting, and your accountant’s job does not shrink — only the typing does.

Where the mapping needs care

This is where integrations succeed or quietly fail, and none of it is difficult. It just has to be decided rather than assumed.

• VAT is not one field. In Sweden, goods transport carries the standard 25 % rate while passenger transport is 6 %, so an operator doing both cannot map “transport” to a single VAT code. Cross-border work adds another branch: a haul sold to a VAT-registered business in another member state is generally reverse-charged to the buyer, so the invoice carries no Swedish VAT and has to say why. Whichever system decides that, decide it on purpose.
• Customer matching needs a stable key. Names are not keys. AB Nordisk Frakt, Nordisk Frakt AB and Nordisk Frakt are one company in reality and three records in an unmatched sync. Match on organisation number where you have it, and agree in advance what happens when a customer exists in one system and not the other: created automatically, or held for a human?
• Currency and rounding. If you sell in EUR and book in SEK, something has to fix the rate and the moment it applied. Two systems each doing their own conversion will disagree by small amounts, forever, and small amounts are exactly what a reconciliation stops on.
• Credit notes. An issued invoice is not edited or deleted; it is reversed by a second numbered document. Ask specifically how a cancellation is handled, because we delete it and send a new one is the wrong answer and it will come up in your first month.
• Who owns the number series. Two systems that both mint invoice numbers will eventually mint the same one. Decide which is the source, and make the other follow.

One direction is usually the right answer

A one-way push is not a limitation to apologise for. The ledger is your legal record: Swedish bookkeeping law requires accounting information to be kept for seven years, and since 1 July 2024 paper originals may be discarded once they have been properly transferred to electronic form — which raises rather than lowers the question of which system is the archive of record. A transport system able to reach into posted entries and change them would be a liability, not a feature.

The sane shape is narrow: the TMS proposes documents, the accounting system accepts and posts them, and a thin return channel reports what has been paid.

The first month is worse, not better

An integration does not pay off on day one. The first month goes on mapping — matching customers, agreeing article codes, settling VAT treatments, finding the handful of customers whose organisation number was never filled in. That work is real, and it lands on the person least able to spare it, usually at month end.

It is still worth doing once, because the alternative compounds. But one failure mode deserves naming plainly: a wrong mapping is worse than retyping. A person keying invoices notices when a line looks odd — an unfamiliar VAT rate, a surcharge on a customer who has never had one. A mapping notices nothing. It applies the same wrong answer to every invoice, silently, until somebody reconciles a quarter. So test with real invoices, in a sandbox company if the vendor offers one, and check the resulting postings rather than the fact that the sync reported success.

Questions to ask before you connect

1. Which accounting systems are supported today, in production, with customers actually running them?
2. Is the connection included, or a billable integration project each time? If every connection is a consultancy line, the integration list is a price list — see choosing a TMS.
3. What exactly transfers: customers, invoices, article codings, VAT codes, payment status? Which direction does each one go?
4. Who does the article and VAT mapping, and can we change it later without the vendor?
5. What happens to a credit note or a cancelled invoice?
6. Which system owns the invoice number series?
7. What happens when the connection fails — is the invoice queued and retried visibly, or lost behind a line in a log nobody reads?
8. Can we disconnect and keep invoicing?

Question seven is the one that separates a working implementation from a convincing demo. Accounting APIs go down, tokens expire, and customer records get rejected for missing fields. What matters is whether you find out the same day or at the quarter.

A note on where this is heading

Electronic invoicing is becoming the default rather than an option. Suppliers to Swedish public bodies have had to send invoices meeting the European standard EN 16931 since the e-invoicing act (2018:1277) took effect on 1 April 2019, with Peppol BIS Billing 3 the recommended format. At EU level, the VAT in the Digital Age package adopted on 11 March 2025 brings mandatory e-invoicing and digital reporting for intra-Community transactions from 1 July 2030. None of that demands action this quarter — but if you are choosing how invoices leave your business, choose something that already produces structured data rather than a PDF and a typist.

Where navichain stands

navichain builds invoices from the delivery data you have already captured — the booking, the price rules, the charges and the VAT — and syncs them to Visma, QuickBooks and Tripletex, carrying customers and article codings across so an invoice arrives ready to post rather than ready to retype. It is part of the product, not a per-connection project. The platform page lists what is inside, and pricing is public.