When your other systems are the constraint

An accounting automation project gets planned around what finance controls. Then it meets the parts of the business that finance does not control, and stalls.

The till cannot export in a usable format. The payroll system has no integration. The warehouse system belongs to a supplier who has no interest in changing it. Half your suppliers send PDFs, and two send paper.

This is where implementations lose momentum, because the blocker is real and it is not in finance's gift to fix.

The four kinds of blocker

No integration exists. The system has no API and no scheduled export. Common in older or highly specialised software.

An integration exists but is poor. Exports totals rather than transactions, or omits the identifiers you need to match on, or runs only on demand.

The integration exists and someone else owns the decision. Technically possible, and it requires another department's cooperation or budget.

The data is fine and arrives in an unusable form. A daily emailed spreadsheet whose columns move.

Each has a different response, and treating them identically is why these conversations go nowhere.

What to do about each

No integration

A scheduled file export is not a defeat. A nightly file, picked up and processed automatically, achieves most of what an API would. It is less elegant, entirely adequate, and the difference matters far less than vendors imply.

Where even that is unavailable, document reading covers a surprising amount — a PDF report read automatically is workable, if unglamorous.

What not to do: rebuild or replace a working operational system to solve an accounting problem. A till that runs the shop well is doing its job. The accounting integration is a separate question from whether the till is right, and conflating them turns a modest project into a large one.

A poor integration

Establish precisely what is missing before deciding anything, because the answer is often narrower than assumed.

If it exports totals rather than transactions: you lose per-item analysis and can still reconcile the money. Frequently acceptable for a first phase.

If it omits identifiers: this is the serious one. Without a key to match on, reconciliation becomes fuzzy matching, which is where errors live. Worth escalating properly.

If it runs only on demand: schedule it, and monitor that it happened. A manual export somebody forgets is worse than a scheduled one that occasionally fails, because the failure is silent.

Someone else owns it

The most common blocker and the least technical.

What works is making it their problem in their terms. The operations manager does not care about your reconciliation; they care that they get asked for figures constantly, that stock discrepancies take days to explain, that they cannot see margin by product.

The integration usually solves something they want. Leading with that rather than with finance's requirement changes the conversation entirely.

Unusable format

Frequently the easiest, and the one people assume is hardest. Document reading handles a great deal of variability, including reports whose layout shifts.

The residual work concentrates in a few sources, which makes it a targeted problem rather than a general one.

The sequencing that keeps momentum

The mistake is treating the blocked part as a prerequisite for the whole project.

Automate what you control first. Bank reconciliation, supplier invoices, whatever does not depend on another system. Get that working and delivering.

Then take the blocker to its owner with evidence. "We reduced invoice processing by this much; the till export is now the constraint" is a materially stronger conversation than a request made before anything has been demonstrated.

Accept a manual bridge in the meantime. A monthly manual import from one system, while everything else is automated, is a reasonable interim position. It becomes a problem only when it is treated as permanent and nobody revisits it.

Put a review date on every manual bridge, or it becomes the permanent arrangement nobody questions.

The uncomfortable case

Sometimes the blocking system genuinely needs to be replaced, and that is a much larger decision than the accounting project.

Signs it is genuinely the case rather than an excuse:

• The data cannot be extracted at all, in any form, including printed
• It is unsupported, and the vendor is gone
• It is the source of errors rather than merely inconvenient
• Several departments are working around it independently

If none of those apply, the system is probably adequate and the integration is the problem to solve. If several apply, that is a separate project with its own case — and it should not be smuggled into an accounting automation business case, because it will fail on the wrong grounds.

Common questions

What if my other systems will not integrate with accounting software?

Establish which kind of blocker it is. Where no integration exists, a scheduled file export achieves most of what an API would and is entirely adequate. Where the data arrives in an awkward format such as an emailed spreadsheet, document reading handles more variability than people expect. Where another department owns the decision, the constraint is organisational rather than technical.

Should I replace a system that will not integrate?

Rarely, and not as part of an accounting project. A till or warehouse system that runs its operation well is doing its job, and rebuilding it to solve a reconciliation problem turns a modest project into a large one. Replacement is warranted when data cannot be extracted in any form, the system is unsupported, it is generating errors rather than inconvenience, or several departments are independently working around it.

How do you get another department to prioritise an integration?

By framing it in their terms rather than finance's. The operations manager does not care about your reconciliation but does care about being asked for figures constantly, stock discrepancies taking days to explain, and not seeing margin by product. The integration usually solves something they already want, and leading with that changes the conversation.

Is a manual data import acceptable?

As an interim position, yes — a monthly manual import from one system while everything else is automated is reasonable. It becomes a problem when treated as permanent, so it needs a review date attached, and it should be scheduled and monitored rather than depending on someone remembering, because a forgotten manual step fails silently.

Related: connecting sales channels to your ledger · integrating AI accounting with your bank · why integration depth beats feature count