This is the build guide for automatic invoice intake at a freight forwarder. Seven steps, from mailbox to booking, the way we set it up at customers. No concept, no tool comparison. At the end you know which check sits where and why.
Ask me where to start and I say: with the process that annoys you most and runs most predictably. Invoice intake meets both. A freight invoice arrives by mail. Someone opens the attachment and reads number, amount and due date. Then finds the order, retypes, files the document. Five to eight minutes per invoice. At 300 freight invoices a month, that is about 30 hours.
The process is rule-based, it repeats, and a mistake can be corrected. (A wrongly booked invoice is annoying. A wrongly reported arrival costs a dock slot.)
There is also a deadline. Since 1 January 2025, companies in Germany must be able to receive e-invoices in B2B business. From 2027, companies with more than 800,000 euros of prior-year turnover must also issue them. From 2028, everyone. (Growth Opportunities Act, Federal Ministry of Finance letter of 15 October 2024.) Whoever automates intake now builds it for structured invoices from the start, with PDFs as the transition.
One mailbox where all freight invoices arrive. Not a shared inbox with newsletters. The service reads it every five minutes, files every mail with an attachment under a case number and remembers what it has seen. If it fails and comes back, it continues where it stopped. Nothing gets lost, nothing gets read twice.
The attachment is either an e-invoice (XRechnung or ZUGFeRD, so XML with or without PDF) or a plain PDF. The e-invoice is the easy case: number, amount, date and lines are fields. For a PDF the service needs a reading rule per sender. It says where the invoice number sits and how the line table looks. Two or three senders usually carry 60 percent of the volume. Start with those.
Here a forwarder's invoice intake parts ways with an accounting firm's. Every freight invoice belongs to a tour, an order or a shipment number. The service finds the reference in the invoice and looks it up in the TMS. If it finds the order, the invoice is attached to it. If not, that is a review case, not a booking.
Now the check that almost never happens by hand, because there is no time. The service compares the invoice amount with the order. Freight price, toll, surcharges, each line on its own. Deviations above a threshold go to the review list, order and invoice side by side. (At most customers the threshold is 2 percent or 20 euros.) Everything below is marked as checked.
In the first weeks this check regularly finds invoices with lines that appear in no order. Nobody saw that before, because nobody lays 300 invoices against 300 orders.
The service books checked invoices into accounting or the TMS, wherever the customer keeps its payables. Interface where there is one, import file where there is not. The file lands in the archive with case number, order number and date in its name. Retention rules make filing part of the process, not an afterthought.
Everything the service could not decide sits in a list. No order found. Amount outside the threshold. Unknown sender. Unreadable attachment. Each line carries its reason. Accounting decides with one click, and the service learns nothing from it on its own. That is deliberate. A decision a person made stays theirs.
Every run writes three numbers: mails read, invoices booked, open review cases. The alarm does not hang on whether the service ran. It hangs on whether it booked. If invoices arrive all morning and nothing gets booked, that is an outage, and we hear about it before the customer does.
You can click the seven steps together in a no-code tool, and for a test that is fine. For operations we build a small program with tests, logging and fallbacks, for three reasons. First: the check against the order needs rules you can read and test. Second: when a sender changes its PDF, the change belongs in one place, not in five nodes. Third: the protocol per step is not an add-on for us, it is the basis for the alarm.
A caveat: this fits 200 to 2,000 invoices a month. Below that, good accounting software with e-invoice intake is often enough. Above it, matching to the order becomes the main work, and then the TMS should own the payables side.
Once intake runs, the data for the next step is already there: reconciling toll, trip data and invoice per tour. Invoice intake comes first because it shows whether the operation trusts a service that books without supervision.
How many freight invoices arrive at your company per month, and how many are checked against the order? Send me the two numbers. I will show you the protocol of one run, review list included. Ask for a process check: 30 minutes, no sales pitch.
