Integration-Agnostic AP Automation: One Payables Process Across Every ERP You Own
Introduction
Ask a group finance director which entity causes the most payables pain and the answer is rarely the newest one. It is almost always the one running the oldest ledger and processing the most invoices. Then ask which gets automated first, and the answer flips: the cloud ledger with a native connector, because that is what an implementation plan can promise quickly.
That inversion is the most expensive pattern in multi-entity accounts payable automation, and it is avoidable. The fix is architectural: stop letting the integration method decide what the process looks like.
Why Does One Entity’s ERP Dictate the Whole Group’s AP Process?
Auditors and consolidated reporting demand consistency. So when one ledger cannot accept automated postings, the instinct is to level down: keep everything semi-manual so numbers stay comparable, sacrificing automation everywhere to accommodate the weakest link.
The opposite instinct is just as damaging. Teams automate the easy entities and defer the awkward one, which is usually where the volume sits. Research on finance transformation finds that partial automation of low-volume processes produces disappointing returns, a pattern explored in Deloitte’s work on digital transformation.
Both failure modes share a root cause: the integration layer is treated as the thing that defines the process, when it should be the last step in it.
What Does Integration-Agnostic Actually Mean?
An integration-agnostic design separates two concerns that are usually tangled.
The first is the control plane: how invoices are captured and coded, who approves what at which threshold, what evidence is retained, and how exceptions are handled. This is the business logic, and it should be defined once for the whole group.
The second is the delivery contract: how an approved transaction reaches a specific ledger. This varies per entity and cannot be standardised, because it depends on what each ERP supports.
Separated, a new entity needs only a new delivery contract, inheriting policy and coding rules. Tangled, every ERP difference becomes a process difference, and the group accumulates as many payables processes as it has ledgers.
The Three Integration Depths You Will Actually Encounter
Most estates mix three categories; identifying each entity’s category is the first step.
| Integration depth | What it supports | Typical latency | Where it fits |
|---|---|---|---|
| Native API connector | Bi-directional sync, real-time validation, instant error feedback | Seconds to minutes | Modern cloud ledgers |
| File-based exchange | Scheduled batch posting via the ERP’s import template | Hours to daily | Legacy and on-premise ERPs |
| No integration | Export for manual upload, or AP platform runs standalone | Manual | Very old systems, entities mid-migration, new acquisitions |
None disqualifies an entity from automation. Capture, coding and approval run identically; only the posting step differs, and the difference is latency, not control quality.
Why the Highest-Volume Entity Often Has the Weakest Connector
The correlation is not coincidence, and understanding why helps make the case.
High-volume entities tend to be the older, operationally heavier parts of a group. Their ledger was chosen for operational depth rather than API quality, and years of customisation now make replacing it risky. Newer entities are smaller, sit on cloud accounting, and have excellent connectors precisely because they have little history - and they process the least volume.
The result is a reliable inverse relationship between invoice volume and integration convenience, so any rollout sequenced by integration ease addresses the least valuable workload first. Bodies such as the Institute of Management Accountants have long emphasised sequencing finance change by volume and risk rather than convenience.
How Do You Keep Policy Identical When Connectors Are Not?
Four disciplines keep a mixed estate coherent:
Hold the approval matrix centrally. Thresholds, vendor categories and budget-category routing belong in the AP layer. Approval logic living in each ERP will drift, and you will find the drift during an audit.
Standardise capture regardless of destination. The same extraction rules, validation checks and exception queue should apply whether an invoice targets a cloud ledger or a batch file. No invoice should get weaker scrutiny because its entity has an awkward connector.
Keep one coding model. Chart-of-accounts structures differ, but the logic selecting a code should be one engine with different mappings, as in our guide to GL coding automation for non-PO invoices.
Separate payment and approval systems of record. One entity may pay inside its own ERP while others pay through the platform, provided approval evidence is central and the reconciliation contract explicit.
What Breaks When You Let the Connector Define the Process
The costs are specific:
| Symptom | Underlying cause | Business consequence |
|---|---|---|
| Two parallel AP processes inside one group | Process designed per ERP rather than per policy | Training burden doubles, controls diverge, audit findings increase |
| High-volume entity still fully manual | Rollout sequenced by integration ease | Majority of invoice effort untouched, ROI case fails |
| Approval thresholds differ by entity | Matrix configured inside each ERP | Inconsistent authority limits, compliance exposure |
| Exceptions handled differently per entity | No central exception queue | No comparable metrics, root causes never addressed |
| Coding quality varies by entity | Separate coding logic per ledger | Month-end reclassification work concentrates in weakest entity |
None of these are integration problems. They are governance problems created by letting integration drive governance.
How to Roll Out Integration-Agnostic AP: A Practical Sequence
Step 1: Map volume against integration depth. Tabulate entities, bill volume and the integration method each ledger supports. Confirm with whoever maintains that ERP rather than trusting documentation.
Step 2: Define policy once, above the connector. Write the approval matrix, coding standards and capture requirements as group policy. Our complete guide to AP automation covers the structure needed.
Step 3: Start with the highest-volume entity. Accept a longer integration timeline because the workload relief justifies it.
Step 4: Standardise the outbound contract per ERP. Agree the template, posting cadence, error-handling path and payment system of record. These trade-offs are examined in our comparison of file-based versus API ERP integration.
Step 5: Reconcile centrally and measure uniformly. Use identical metric definitions, or you cannot tell an integration problem from a process problem.
| Rollout sequenced by | First entity live | Share of group volume automated first | Typical outcome |
|---|---|---|---|
| Connector convenience | Fastest, often 2-4 weeks | Smallest, frequently under 15% | Quick win, weak business case, hard entity deferred indefinitely |
| Invoice volume | Slower, often 8-12 weeks | Largest, frequently 50-60% | Slower start, majority of manual effort removed, remainder self-funding |
How Peakflo Helps
Peakflo is built so the payables process does not change when the ledger does. Capture, AI-based GL coding, multi-dimensional approval routing and the exception queue sit in a control layer above the accounting system, so one policy governs every entity regardless of what runs underneath.
Delivery is handled per ledger on its own terms. Native connectors cover cloud systems including Xero and NetSuite, while SFTP and file-based integration serves legacy ERPs with no usable API, posting in the destination’s own import template. Entities needing to retain payment execution in their existing ERP can do so while routing approvals centrally. Supported systems are listed in the integrations directory.
Integration capability therefore stops being a scoping filter, letting you sequence by invoice volume. To map this to your entity structure, request a demo.
Our Verdict: Sequence by Volume, Not by Connector
Our recommendation:
Adopt an integration-agnostic design when
- You operate two or more entities on different accounting systems
- At least one significant entity runs a ledger without a modern API
- Invoice volume is unevenly distributed across entities
- You need comparable controls for audit or consolidation
- Replacing the legacy ERP is unrealistic within 18 months
Reconsider or simplify when
- All entities already run the same cloud ledger, where a native connector suffices
- Group volume is low enough that manual handling remains cheaper
- An ERP consolidation programme is funded and imminent, in which case align with it rather than building around a system being retired
Our Recommendation: Rank entities by monthly invoice volume and automate in that order regardless of integration difficulty. Accept file-based exchange where APIs do not exist rather than deferring the entity. Keep policy central and let only the delivery contract vary. Groups following this sequence typically bring 60-80% of invoice traffic under automation before meeting their hardest integration, which funds the remainder.
Conclusion
The question is not which systems can be integrated. It is which invoices cost the most to process, and what actually prevents those invoices from being automated.
In most groups the answer is not a technical limitation. The rollout was scoped around connector availability, and the entity generating most of the workload sat on the wrong side of that filter. Integration-agnostic design removes the filter, returning the connector to where it belongs: a detail at the end of the workflow. For regional context see our Southeast Asia AP automation guide; on governance, IFAC, ACCA and Corporate Finance Institute are useful references.
Frequently Asked Questions
What does integration-agnostic AP automation mean? Capture, coding, approval routing and audit trail run identically regardless of how the underlying ledger connects. The ERP connection becomes a delivery detail at the end of the workflow rather than the constraint that shapes it.
Why does the weakest ERP connector often govern the whole group’s AP process? Teams design the process around what every entity can support. If one ledger cannot accept automated postings, groups drop back to manual everywhere so reporting stays consistent, sacrificing automation at entities that could have had it.
Should we automate the entity with the best API first? Usually not. That optimises for implementation speed, not business value. If most invoice volume sits on a legacy ledger, automating a low-volume cloud entity first gives a fast deployment with little workload relief.
Is file-based integration a downgrade compared with an API? It is a different trade-off. File exchange gives up real-time sync and immediate error feedback, but it is predictable, auditable, cheap to maintain and works with ledgers that have no usable API.
Can different entities keep different payment systems of record? Yes, and often they should. One entity may execute payments in its own ERP while others pay through the AP platform. Approval evidence and the reconciliation contract must stay consistent, not the execution venue.
How do we stop two AP processes emerging inside one group? Hold policy in the AP layer rather than in each ERP configuration. When thresholds, coding logic and capture standards are defined once centrally, entities differ only in how postings are delivered.
What metrics prove integration-agnostic AP is working? Straight-through processing rate, exception rate, touchless invoice percentage and approval cycle time, measured per entity with identical definitions. If the file-based entity trails on cycle time, the gap is process rather than plumbing.
Does integration-agnostic mean we never build an API connector? No. The choice is made on merit per ledger. Where a mature API exists, use it. Where it does not, use file exchange rather than delaying rollout or forcing an ERP upgrade.
How long does a mixed-estate rollout usually take? Cloud ledgers with native connectors are often live within a few weeks. File-based entities take longer because the template, posting cadence and error-handling path need agreement, often involving the ERP consultant.
What is the most common mistake groups make here? Treating integration capability as a scoping filter. Entities on awkward ledgers get postponed indefinitely, and that is usually where volume and manual effort concentrate, so the business case never materialises.