If you tell almost anyone in software that a manufacturer is drowning in reconciliation work or they’re unable to digitise Operations, you get the same answer within about thirty seconds. “Have you heard of tool X or Y?” Get the accounting package talking to the operations platform, wire in the retailer feed, automate the sync. Best of breed…connected. And lately you get the added pearl of wisdom to write a prompt to help you automate that recon.
It is the received wisdom of the last decade and it is genuinely right for a certain kind of company. It is close to useless for the businesses I have been speaking to, and I think the reason is more nuanced than it first appears.
The setup and maintenance nobody costs in
An integration is not a thing you buy. It is a thing you build and keep.
Every connection between two systems is a small piece of permanent infrastructure. It has to be monitored, because it will fail silently. It has to be updated, because both sides ship changes on their own schedule and neither is asking your permission. It has to be understood by somebody, because when the numbers stop matching, the first question is which side broke and nobody can answer that from the outside.
In an enterprise, that is fine. There is a team whose job this is. There is someone who owns the middleware, someone who watches the error queues, a support contract with a partner who takes the call.
In a business of ten people, there is no such person. There is an operations lead already doing three jobs, a finance co-founder who is also the co-founder, and a factory that has to run today. When an integration quietly stops syncing on a Tuesday, nobody notices until the month-end numbers do not tie up, and then it is not a technical problem anymore. It is a week taken away from something else.
So each integration you add to solve a data problem creates a maintenance problem. And maintenance problems do not scale down. They land on whoever has “capacity” to absorb them, which in these businesses is always the same two or three people.
This is the part the received wisdom skips. Best-of-breed plus integration is not a neutral architecture with a setup cost. It is an ongoing operational commitment, and it assumes an IT function that these businesses do not have and cannot justify hiring.
Connected is not the same as reconciled
There is a second problem, and it is the one that actually explains why the expensive systems have not solved this either.
Integration moves data. It does not resolve disagreement.
When a major retailer sends a remittance, the mismatch is not caused by the data sitting in two different places. It is caused by two separate organisations describing the same transaction differently. Different reference numbers, different line groupings, deductions applied at their end for reasons that arrive later or not at all, a delivery split across dates that your invoice treats as one.
No amount of syncing fixes that, because there is nothing to sync. Both sides are internally consistent and mutually unintelligible. Someone still has to sit down and decide what corresponds to what, and that judgement is the work.
Which is why the business paying fifteen thousand dollars a year for a serious system, with a live electronic connection into their largest customer, still has someone matching hundreds of lines by hand. They are the most connected business I spoke to.
It made no difference to the thing that hurts!
The uncomfortable part of the argument
The obvious response to all of this is that the answer is a single system that holds operations and accounts together, and that this already exists, and it is called an ERP.
That is fair, and I want to meet it directly rather than pretend it is not the case.
The single-system idea is correct. If your stock movements, your invoicing, your costs and your ledger live in one place, there is no internal reconciliation, because there are not two versions of the truth to reconcile. That is a real and significant advantage and it is why ERP won the enterprise.
The implementations available to the entry and mid-market are what fail, and they fail in three specific ways.
They are priced for a business several times the size. The manufacturer I spoke to is watching that bill double, for reasons that have nothing to do with their usage and everything to do with a vendor repositioning upmarket.
They carry enormous surplus. That business uses somewhere between a fifth and a third of what they are paying for. The rest is not missing capability, it is purchased capability sitting idle, and every unused module still contributes to the complexity of the thing they have to operate.
And critically, they stop at the company boundary. The single system unifies everything inside the business, and then hands you a spreadsheet at the edge, where the retailer’s version of events arrives. The hardest reconciliation in these businesses is not internal. It is external, and no ERP owns it.
So “you need one system” is not sufficient. The honest version is that these businesses need one system built for their actual shape, and it has to reach past the walls of the company to be worth anything.
What should exist
Three properties, and none of them is a feature list.
One source of truth that spans operations and accounts. Not two systems in sync. One record, where a stock movement and its financial consequence are the same event rather than two events that have to be matched later. This removes internal reconciliation as a category of work rather than automating it, which is a meaningfully different outcome.
Ownership of the external join. The messy work at the boundary, matching a customer’s remittance to your own invoices across mismatched references and unexplained deductions, has to be a first-class part of the system rather than the thing you export to Excel to deal with. This is the gap every operator I spoke to identified as their worst week, and it is currently owned by nobody. Not the ERP vendor, not the accounting package, not the retailer, and not the accountants, who have looked at this work and declined the segment because of it.
Only what this business actually uses. The discipline is subtractive. A business of ten people should not pay for, learn, or navigate around modules built for a business of two hundred. Surplus capability is not free optionality. It is weight, and weight is what makes systems go unused.
None of that is technically exotic. It is unfashionable, because it runs against a decade of best-of-breed orthodoxy, and it is commercially unattractive to incumbents, because it means selling less software at a lower price to customers who are harder to reach.
Which is roughly why it does not exist yet.
The point
The reflex answer to fragmented operations is more connections. For a business with an IT function, that works. For a business of ten people, every connection is another thing to maintain and another way to be wrong at month end.
They do not need their systems talking to each other more fluently. They need fewer systems, covering more of the ground, including the part outside their own walls where the real disagreement happens.
That is a harder product to build than an integration marketplace that eats up more of your margin. It is also the only version I have seen that matches what these businesses actually described to me.