.svg)
The single most common reason AP and AR automation projects underdeliver is not the technology. It is the integration.
A finance team can select the best-in-class AP automation platform, configure it correctly, and train every member of the team on it. If the integration with the ERP is shallow, the results will be disappointing. Data re-entry persists. Reconciliation remains manual. The promised efficiency gains do not materialise because the system boundaries have not actually moved.
This guide covers what genuine ERP integration means in a finance automation context, how to evaluate vendor claims before signing, and what the right questions look like for the ERPs that mid-market businesses most commonly use.
The word "integration" is one of the most overloaded terms in enterprise software. Every vendor claims to integrate with major ERPs. What that claim covers varies enormously.
At one end of the spectrum, integration means the ability to export a file from the ERP, upload it to the AP platform, do some work, export a file from the AP platform, and import it back into the ERP. This is technically a connection between the two systems. It is not integration in any meaningful sense. It replicates, rather than eliminates, the manual steps in the process.
At the other end, genuine integration means that data moves automatically and in real time between the two systems, without any human action. An invoice approved in the AP platform is reflected in the ERP immediately. A purchase order raised in the ERP is visible in the AP platform for matching purposes immediately. A payment recorded in the ERP updates the AP ledger without anyone touching it.
The gap between these two definitions is where most integration disappointments live.
A connector links two systems. Real integration means those systems share a live, bidirectional data flow that keeps both sides current without manual intervention.
Ramp's 2026 analysis of AP automation challenges identifies ERP integration as one of the most complex hurdles in AP automation, specifically because "legacy systems often use rigid data structures, require manual file uploads, or operate in batch processes, none of which align with the real-time, interconnected nature of AP automation."
The result, when integration is connector-level rather than genuine, is predictable: teams build workarounds, deal with data inconsistencies, or revert to manual reconciliation. The automation covers the AP or AR workflow but stops at the ERP boundary. And the finance team ends up managing two systems rather than one.
Shallow integration creates specific, recurring problems:
Double data entry. Information entered in the AP platform has to be re-entered in the ERP. Every re-entry is an opportunity for error and a source of reconciliation work.
Lag in financial reporting. If data syncs from the AP platform to the ERP in a nightly batch, the ERP is always at least a day behind. Month-end close requires reconciling the two rather than simply closing the books.
Broken audit trail. When approvals happen in one system and payment records live in another, the audit trail is split across two places. Producing a complete record for an auditor requires manual consolidation.
Manual reconciliation at period-end. The full cost of shallow integration is most visible at month-end, when the finance team spends hours confirming that what the AP platform recorded matches what the ERP shows.
Research from SoftCo citing a global manufacturing case study found that after integrating SAP with AP automation software properly, invoice cycle time dropped from 18 days to just 6, and vendor disputes reduced by over 50%. The improvement was not from the AP automation alone. It was from the integration that made the two systems act as one.
For AP automation to work accurately, it needs continuous access to:
For AR automation, the equivalent inbound data includes: customer master, sales orders, payment terms, and the AR ledger balance.
Once the AP or AR platform has processed a document, the results need to flow back to the ERP without manual export:
The defining feature of genuine integration is bidirectional, real-time sync. Both systems are always current. Neither system requires a manual step to update the other.
Batch syncs, typically nightly or hourly, are an improvement over manual file uploads. But they introduce a lag that creates specific problems: the ERP shows an invoice as outstanding that was approved in the AP platform four hours ago. The AP platform shows a payment as pending that was confirmed in the ERP's banking connection this morning.
For finance teams trying to manage working capital actively, as we covered in the cash flow forecasting guide, that lag is not a minor inconvenience. It is the difference between acting on current information and acting on stale information.
A native connector is a pre-built integration between the AP/AR platform and a specific ERP, developed and maintained by the vendor. It is the fastest path to integration and the lowest-maintenance option for the finance team.
The key questions to ask about any native connector:
An API integration is built to specification rather than pre-built. It can cover exactly the data flows required, handle complex logic, and be maintained to match any ERP configuration. The trade-offs are implementation time, initial cost, and ongoing maintenance: someone needs to update the integration when either system changes.
For businesses with highly customised ERP configurations, an API integration is often the right choice. For businesses with a standard ERP setup, a well-maintained native connector is typically faster to implement and cheaper to run.
Middleware, sometimes called an integration platform or iPaaS, sits between the AP/AR platform and the ERP, translating data between the two. It is useful when a native connector does not exist for the specific ERP version in use, or when the data transformation required is complex enough to warrant a dedicated integration layer.
Ramp's 2026 analysis recommends middleware as a fallback when "direct connections are not feasible," but notes that it adds a third system to maintain and can introduce its own latency if not configured carefully. For most mid-market businesses with standard ERP configurations, middleware is the right answer when no native connector exists, not the default approach.
SAP is the most widely deployed enterprise ERP globally. Integration with AP automation platforms typically occurs through SAP's standard APIs or through SAP's own integration framework. Key considerations:
Business Central is the primary ERP for mid-market businesses in the UK and across Europe. Its cloud-native architecture makes API integration more straightforward than on-premise ERPs, and its marketplace includes a number of pre-built AP automation connectors.
Key considerations for Business Central integration:
Sage's product range covers different market segments. Sage 200 is the standard mid-market product, Sage Intacct is the cloud-native option increasingly popular in the UK, and Sage X3 is the enterprise-level offering.
Each has different integration capabilities. Sage Intacct's API is well-documented and supports real-time integration reliably. Sage 200 integration requires more careful configuration, particularly around the direction of data flow for payment posting. Sage X3 integration is typically the most complex and most likely to require either a native connector or middleware.
The Sage connector landscape changes with each product update. Confirm with any vendor that their Sage integration has been tested and maintained against the specific version your business runs.
Oracle ERP integration for mid-market businesses typically involves Oracle NetSuite (cloud) or Oracle Fusion (enterprise). NetSuite has a well-supported integration ecosystem and REST APIs that AP automation vendors commonly support. Oracle Fusion is more complex and typically requires a more custom integration approach.
For either Oracle product, the critical question is whether the AP automation vendor has an existing, maintained connector or whether they are building one specifically for your implementation.
These questions should be answered in writing before contract signature:
Dost integrates natively with SAP, SAP Business One, Microsoft Dynamics 365 Business Central, Sage 200, Sage Intacct, Sage X3, and Oracle. The integration is bidirectional and real-time: AP and AR data flows between Dost and the ERP continuously, without manual steps, file transfers, or batch syncs.
The intelligent data extraction that reads incoming invoices feeds directly into the ERP's vendor master and chart of accounts. The 3-way matching pulls purchase orders from the ERP in real time. The approval workflow reflects the ERP's approval hierarchy without requiring manual configuration duplication. And payment confirmations update the AP ledger in both systems simultaneously.
The integration is ready from day one. Not after a configuration project. Not after a middleware implementation. From the first invoice processed.
Book a demo to see Dost's ERP integration working with your specific setup.
It depends significantly on the integration approach and the ERP configuration. For businesses using a supported ERP in a standard configuration, a native connector integration typically takes two to four weeks from contract to go-live. API integrations with custom ERP configurations can take two to four months, particularly if custom fields or complex approval hierarchies need to be mapped. Middleware-based integrations fall in between. The implementation timeline is one of the most important questions to press vendors on during evaluation: ask for a realistic timeline based on customers with your specific ERP version, not a best-case estimate.
For standard ERP configurations with supported connectors, the integration is handled by the Dost implementation team with minimal IT involvement. The finance team leads the project. IT is typically involved in two areas: confirming access credentials for the ERP API connection, and reviewing security and data governance requirements. The ongoing maintenance of the integration after go-live does not require IT involvement for standard operations.
Nothing. ERP integration for AP automation does not modify the data structure of your ERP. It reads from and writes to your ERP using the ERP's standard data model. Your existing vendor records, chart of accounts, historical transactions, and configuration remain unchanged. The integration adds a new data flow to and from the ERP. It does not alter what is already there.
ERP integration is not a feature of AP and AR automation. It is the foundation on which the entire value case rests. An AP automation platform that operates alongside an ERP rather than inside it produces only partial results: some efficiency gains in the AP workflow, but manual reconciliation, data re-entry, and lagged reporting at the ERP boundary.
The finance teams that see the most significant and durable improvements from AP and AR automation are the ones that invested the time to evaluate integration depth rather than integration breadth during vendor selection. Not which ERPs a vendor "supports," but how that support works technically, what data flows in which direction, and what happens when either system changes.
Getting those answers before signing takes effort. It is significantly less effort than discovering the limitations six months after go-live.
See how Dost's native ERP integration works for your business.
