Most small businesses run two worlds. One is where the work happens — jobs, quotes, customers, schedules. The other is where the money is recorded. Between them sits a person doing data entry.
That gap costs more than the time it takes.
What it actually costs
The retyping. Visible and usually underestimated.
The errors. A digit transposed in an invoice, a job invoiced twice, a job never invoiced at all. The last is the expensive one and the hardest to detect.
The delay. If invoices are raised in a monthly batch, you have added an average of a fortnight to every payment cycle for no reason.
The blindness. Nobody in operations can see whether a customer has paid, so people either guess or interrupt the finance team.
Decide who owns what
Before any technical work, settle ownership. This is the decision that determines whether the integration holds together.
Customer records. Usually the operational system owns the relationship — contacts, addresses, notes — and accounting owns the financial identity. They link via a shared reference stored in both.
Products and prices. Whichever system you quote from should own them. Two price lists will diverge.
Invoices. The accounting system owns them once raised, including the numbering. Operations may create them; accounting is authoritative.
Payments. Accounting owns this absolutely. Nothing else should ever mark something as paid.
Every field needs exactly one owner. Where two systems both believe they own something, they will disagree, and no amount of synchronisation will settle it.
What flows, and which way
Operations to accounting
New customers, created once and matched by reference thereafter.
Invoices, with enough line detail to support reporting. Summarising everything into one line saves effort now and removes your ability to analyse revenue later.
Credit notes, which are frequently forgotten in integrations and then handled manually forever.
Accounting to operations
Payment status. The most valuable single flow. It lets anyone dealing with a customer see whether they are settled, without asking.
Credit position, if you offer accounts, so orders can be checked against it.
Overdue status, so it is visible where the customer conversation happens rather than only in the aged debt report.
Getting the data ready first
Integration projects fail on data, not on code.
Customer matching. How will the two systems know they mean the same company? Matching on name fails, because one system has "Smith & Sons Ltd" and the other has "Smith and Sons". Establish a shared reference and populate it before connecting anything.
Duplicates. Both systems will have some. Clean them first — an integration will otherwise faithfully replicate the mess.
Product codes. If invoices carry line items, the codes need to correspond.
Tax treatment. Both systems must agree on rates and rounding, or every invoice will be a penny out and nothing will reconcile.
Handling failure properly
The difference between an integration that works and one that generates constant reconciliation is entirely in what happens on a bad day.
- Retries with a sensible pause, because transient failures are routine.
- A queue for what could not be processed, visible to a person, rather than silent loss.
- Alerts when something has been failing, sent to somebody who will act.
- Repeat protection, so the same invoice arriving twice does not create two.
- A reconciliation report, comparing totals in both systems daily. This is what catches the slow divergence that nothing else will.
The general principles are in how systems talk to each other. The reconciliation report is the one specific to finance, and it is the one most often omitted.
Where it goes wrong afterwards
Somebody edits directly. A price changed in the accounting system rather than in the source. Restrict where you can and audit where you cannot.
A silent failure. The sync stopped in March and nobody noticed until the year end. Alerting prevents this and is frequently skipped.
Manual invoices raised outside the process. Now the operational system does not know about them. Decide whether that is permitted and, if so, how they get back.
Start with one flow
Do not attempt everything at once. Take invoices from operations to accounting, prove it over a month, then add payment status coming back.
Those two flows deliver the great majority of the benefit, and each is useful before the next is built.
Our integration team connects operational and accounting systems for UK businesses, with reconciliation reporting as standard. Start a conversation if somebody is retyping invoices in your business.
