If you're evaluating AP automation tools, you'll see two architectural patterns. Most cloud-native tools — Tipalti, Stampli, Bill, Basware in cloud mode — extract invoice data on their side and push it into your ERP via middleware. A smaller set of tools embed directly inside the ERP itself.

To finance teams, both look the same: invoices come in, get extracted, get posted. To auditors, they're not the same at all.

What middleware does to your audit trail

When AP automation runs through middleware, the data crosses a system boundary on its way into your ERP. That boundary creates audit complexity.

• Posting transactions are created by a service account, not the user who reviewed and approved the invoice. Your audit trail shows 'AP_SERVICE_USER' as the document creator, not the actual approver.
• The full chain of approval, escalation, exception, and override lives in the cloud tool — separate from the ERP's standard audit log. To reconstruct the story for an auditor, you need both systems' logs and a way to correlate them.
• If the middleware fails mid-flight, you can have invoices that exist in the cloud tool but not in the ERP, or vice versa. Reconciling these is a manual process that auditors love to ask about.

For SOX-relevant entities, internal audit reviews, and external auditor field work, this middleware boundary creates work. Often a lot of it.

What native integration looks like

Native integration means the AP automation runs inside the ERP — using the ERP's own scripting layer, transaction infrastructure, and authorisation model.

When that's the case:

• Posting transactions show the actual approver as the document creator. The audit trail is the ERP's standard audit trail. There is no second log to correlate.
• Approval workflows use the ERP's standard workflow engine — the same one your auditors already understand.
• Exception handling runs through the ERP's standard exception screens. There's no parallel exception system living elsewhere.
• The whole process is contained inside one system. If the ERP is up, AP automation is up. If it's down, neither runs. There is no in-between state.

For auditors, this is dramatically less work. The conversation shifts from 'let me explain how our cloud AP tool talks to our ERP' to 'this is just a process running inside our ERP.'

The trade-off

Native integration isn't free. It requires expertise in the ERP's own scripting environment — which is rarer and more expensive than generic cloud development. It requires deeper integration testing for ERP upgrades. It can be slower to add features that don't have a natural ERP equivalent.

Cloud middleware is faster to build, easier to scale, and gives the AP vendor more flexibility. That's why most AP automation tools chose it.

But the trade-off lands on you, the customer, in the form of audit complexity. You take on the cost of explaining the architecture to your auditors, year after year, in exchange for the vendor's faster development.

What to ask AP vendors

When you evaluate AP automation, ask:

1. Where does the posting transaction physically execute — inside our ERP or in your cloud system?
2. Whose user ID appears as the document creator — the approver's, or a service account?
3. Is the approval audit trail in our ERP's standard audit log, or in a separate system?
4. If your service is down, can our AP team still close the books?

Vendors using cloud middleware will give you reasonable but technical answers about service accounts, batch syncing, and resilience. Vendors using native integration will give you a one-line answer: 'It runs inside your ERP.'

For finance teams that get audited every year, the second answer is materially better.