How do invoice approval workflows and SoD work in my ERP - and when do you need an AP layer on top?

Whichever system the approval actually happened in. If approvals occur in a bolt-on AP layer and only a posted result flows to the ERP, the AP tool holds the approval evidence and auditors will test it there - so it must capture the full trail (who, when, authority, context) and export cleanly. The common failure is approving in one system while assuming the ERP holds the proof: invoices show posted with no approver recorded, because the approval metadata didn't write back. The control design rule is to be deliberate - pick where approval evidence lives, ensure that system captures it immutably, and make sure the ERP posting links back to it.

Native keeps everything in one system (simpler audit scope, no integration risk) but often forces compromises: rigid routing, weak mobile approval, approvals detached from the invoice image, and audit trails that are hard to export. A dedicated AP layer typically offers richer routing, context-rich and mobile approval, line-level matching, and a purpose-built audit trail - at the cost of an integration that itself must be controlled (interface completeness, change management). The deciding factor is complexity: simple processes are well-served natively; multi-entity, multi-dimensional, exception-heavy AP usually outgrows native routing and benefits from a layer that mirrors the ERP rather than fighting it.

Either push the ERP's configuration as far as it goes (often hitting limits on combined conditions) or add a dedicated AP layer that routes on multiple ERP-aligned dimensions at once. The signal you've outgrown native is workarounds - manual re-routing, spreadsheet-tracked authority, approvals that don't reflect the real matrix.

Map the AP functions (vendor maintenance, entry, approval, payment, reconciliation) to ERP roles so no user holds a conflicting combination, then test actual permissions against your SoD matrix. ERPs vary in how granular their AP roles are; where native roles are coarse, a dedicated AP layer can enforce finer separation that the ERP alone can't.

Most ERPs keep object/field history and a transaction log, but completeness and exportability vary - some capture limited approval context, and exports can be clunky. Confirm what's actually logged (does it show what the approver saw?) and test the export before audit season; gaps here are a common reason teams adopt a purpose-built AP audit trail.

Through bi-directional integration: the AP layer mirrors ERP master data and structure, routes and approves on those values, then posts the approved invoice back. The approval evidence stays in the AP layer; the ERP gets the posted transaction. Sync must be monitored so approved invoices actually post and nothing fails silently.

Both, with the approval-control testing focused on wherever approval occurs - the AP tool - and the ERP tested for posting, master data, and its own controls. Auditors will also test the interface between them. Expect the AP tool's SOC report and audit trail to be in scope precisely because that's where the key control operates.

First clarify the intended design: many setups intentionally keep approval evidence in the AP tool and post only the result, so "no approver in the ERP" may be expected - the evidence lives in the AP layer. If approver write-back is supposed to happen, check the field mapping and sync configuration. Either way, confirm where the approval evidence authoritatively lives and that it's complete there.

Restrict ERP-side invoice entry and posting permissions so the controlled AP workflow is the only sanctioned path, leaving direct-entry rights only to a tightly limited, monitored set for genuine exceptions. An open back door - anyone posting invoices straight into the ERP - defeats every control the AP workflow enforces.

Use a consistent global framework (role definitions, control principles) with per-entity calibration where scale, authority limits, or local requirements differ. A system that mirrors each entity's ERP structure lets you run entity-specific routing without rebuilding the design per subsidiary - consistency for audit, flexibility for local reality.

Stampli is ERP-native by design - it mirrors the chart of accounts, entities, dimensions, and approval hierarchies and syncs bi-directionally in real time, so approval routing runs on the same financial structure the ERP maintains rather than a parallel model. Approval happens inside Stampli on the invoice itself, where the full immutable trail (approvers, authority, context, delegation) is captured and exportable - Stampli holds the approval story while the ERP remains the system of record for the posted transaction. Pre-validation before posting and export-error handling address the interface-completeness concern, surfacing failures instead of posting silently, across native API and bridge integrations to 70+ ERPs.