Route accounting sits between the vehicle and the general ledger. It generates financial transactions at the edge of the network, offline, at volume, and every one of them must land correctly in the ERP. This is the hardest integration in the route software estate.
The flows
| Flow | Direction | Frequency | Failure impact |
|---|---|---|---|
| Customer master | ERP → RA | Daily or on change | Wrong pricing, wrong terms, invoicing to closed accounts |
| Product master and pricing | ERP → RA | Daily | Wrong prices, missing SKUs on the van |
| Orders (presell) | ERP → RA | Continuous | Missing deliveries |
| Stock availability | ERP → RA | Daily | Load-out against stock you do not have |
| Invoices and credits | RA → ERP | Per settlement | Revenue not recognised, customer not billed |
| Payments and collections | RA → ERP | Per settlement | Cash not applied, false debt chasing |
| Stock movements | RA → ERP | Per settlement | Inventory position wrong |
| Deposits and returnables | RA → ERP | Per settlement | Balance sheet misstatement |
| Credit status and holds | ERP → RA | Multiple times daily | Delivering to customers on stop |
The credit hold flow deserves attention. If a customer is placed on stop at 09:00 and the driver's device does not know until the evening sync, you have delivered goods you should not have — a control failure that finance will treat seriously.
Every ledger entry should trace to a settlement, every settlement to a route-day, every route-day to a set of invoices, and every invoice to a stop.
Designing it
Establish the system of record per object, unambiguously.
- Customers, products and prices: the ERP, always. Route accounting consumes them.
- Van stock: route accounting during the day, reconciled to ERP at settlement.
- Invoices: created in route accounting, posted to ERP as the financial record.
- Payments: captured in route accounting, applied in the ERP.
Dual maintenance of any of these — someone editing a price in both systems — produces errors that are extremely hard to diagnose later.
Settle then post. Financial transactions should post to the ERP after settlement closes, not as they occur. Posting individual invoices in real time means posting transactions that may be voided or corrected during settlement, and reversing them in a general ledger is painful.
Batch by settlement. One posting batch per driver per day, with a reference that lets finance trace any general ledger line back to a route, a day and a driver. This single design choice removes most month-end reconciliation pain.
Where it breaks
Customer hierarchy mismatch. ERP customers are billing entities; route accounting needs delivery points. A single ERP account may cover fifty stores. If the mapping does not exist, build it deliberately — it will not emerge from the integration.
Unit of measure. The ERP sells in cases; the van tracks units; the customer orders in layers. Conversion factors must exist for every SKU, be maintained, and be identical on both sides.
Tax. Tax calculated on the device must match tax calculated in the ERP, to the penny. Rounding differences at line level compound across thousands of lines and produce reconciliation differences that finance cannot sign off.
Timing. Settlement at 18:00, ERP posting cut-off at 17:00, and a month end on a Friday. Agree the calendar explicitly, including what happens on the last working day of the period.
Corrections. A settlement re-opened after posting must generate a controlled correction, not a silent overwrite. Define the process before you need it.
Volume. A hundred routes each producing several hundred lines is tens of thousands of records a day. Test at peak volume; systems that work at pilot scale sometimes do not at production scale.
Reconciliation controls
Run these daily, automatically:
- Invoice count and value: route accounting versus ERP posted
- Payment total: collected versus applied
- Stock movement value: issued versus received
- Settlements closed but not posted — should always be zero after the posting window
- Postings rejected by the ERP, with an owner and an ageing report
The fifth is the one that quietly kills integrations. Rejected postings accumulate in an error queue nobody owns, and three weeks later the ledger is materially wrong. Assign a person, report the queue depth daily, and treat non-zero as an incident.
Middleware or point to point?
Point to point is acceptable for a single ERP and a single route accounting product with a supported connector. Consider middleware when:
- You have multiple ERPs, typically after acquisitions
- You need to transform or enrich data in flight
- You want monitoring, retry and alerting as configuration rather than as bespoke code
- You expect to replace one of the systems within the contract term
Middleware adds cost and a component to operate. Below four integrations it is usually not justified; above that it usually is.
Common questions
Should invoices be created in route accounting or in the ERP?
In route accounting, because they are created at the stop with the customer present, offline, with a signature. The ERP receives them as posted financial documents. Attempting to create them centrally after the fact loses the point-of-delivery evidence that makes them defensible.
How do we handle a customer placed on credit hold mid-day?
The status must reach the device before the next stop. Design for near-real-time push of credit status, and define the driver's action when a hold arrives — deliver on a cash basis, or return the goods. Waiting for the evening sync is not acceptable in a credit-controlled environment.
What if the ERP cannot accept the volume of transactions?
Aggregate. Post summary journals by route, day and account rather than line-level detail, keeping the detail in the route accounting system with a documented drill-down path. This is a common and entirely defensible design provided traceability is preserved.
Who owns the integration after go-live?
Name someone. Integrations without an owner degrade silently: a new SKU type is added that the mapping does not handle, a tax rate changes, an ERP upgrade alters a field. A monthly integration health review of ten minutes prevents most of it.
How long does ERP integration take?
For a standard connector to a mainstream ERP with clean master data, six to ten weeks. For a customised or legacy ERP, three to six months, and it will be the critical path of the whole project. Budget accordingly and get the scope priced separately.
