AP automation with an ERP: map the work before adding software

An ERP can already own supplier records, purchase orders, receipts, accounting and payment status. It may also include invoice capture, matching or workflow capabilities. The useful question is not whether an ERP can automate accounts payable. It is which licensed capabilities your organisation uses today, and what work still falls between them.

Map that work before adding another product. The result is a more honest evaluation and a clearer integration scope.

Inventory the current capability

Bring finance, ERP ownership and IT into the same review. Start with the systems and modules that are actually licensed, configured and supported—not a generic feature comparison.

For each invoice path, record:

• how PDF and XML invoices arrive, including email, API, SFTP or upload;
• which header and line values are captured;
• where supplier and duplicate checks happen;
• how purchase orders and receipts are retrieved;
• how two-way, three-way and non-PO invoices are handled;
• where coding, allocation, approvals and corrections take place; and
• how approved information reaches the ERP and payment status returns.

This inventory may reveal functionality that can be configured in the current stack. It may also show manual handoffs that need a different workflow.

Follow the work around the ERP

Look beyond the successful transaction. Where do people open the source invoice, rekey a line, search for a receipt, ask who owns an exception or move information between queues?

Common gaps worth testing include inconsistent intake, missing context during review, unclear tolerance failures, manual non-PO coding, approval chasing and poor visibility across unresolved work. These are evaluation prompts, not a claim that every ERP has the same limitations.

Write down the current owner and destination for each handoff. If a step is intentionally manual for control reasons, preserve that reason rather than assuming automation is the goal.

Separate capture, verification and matching

Reading an invoice is only one part of the AP process. A controlled workflow can:

1. capture invoice headers and line items;
2. check supplier and master-data context;
3. apply the correct PO, receipt or non-PO path;
4. compare values using configured thresholds and tolerances;
5. route blocking issues and approvals to people; and
6. return approved information to the agreed ERP process.

Each stage needs its own acceptance criteria. A correctly extracted total does not prove that the invoice matches a purchase order. A successful match does not prove that the approval or ERP handoff completed.

Define the system boundary

Treat the ERP as the system of record where that is the chosen architecture. Agree which system owns suppliers, purchase orders, receipts, coding, approvals and final posting. Then document the records that cross the boundary and the direction of each exchange.

The implementation scope should cover field mappings, access, entity and role boundaries, authentication, retries, duplicate handling, error ownership and reconciliation. SSO and SAML requirements are scoped with the IT team during implementation.

XML intake does not prove compatibility with every national e-invoicing format or network. Confirm the actual schema, transport and validation requirements. AP Automate reports payment status; it does not execute payments.

Make exception ownership explicit

Clean demonstrations understate the work. Include a missing receipt, an invoice outside tolerance, a non-PO invoice needing allocation, a supplier-master issue and a correction sent back to the originator.

For each exception, ask:

• What caused the block?
• Which source and ERP context can the reviewer see?
• Who owns the next action?
• Can the item be sent back, corrected, recalled or reassigned?
• What activity and decision context remains for audit and reporting?

Automatic verification should move work only when the configured checks pass. Blocking issues still need to be resolved through the agreed process.

Evaluate with representative work

Agree a document set that covers the real intake channels, invoice paths, entities and exceptions. Measure extraction, matching, review effort and destination delivery separately. Do not infer a guaranteed saving or accuracy result from a clean subset.

Confirm how the existing ERP capability and the proposed workflow divide responsibility. The evaluation should show whether the extra layer reduces a real handoff or merely relocates it.

Where AP Automate may fit

AP Automate brings intake, verification, matching, allocation, approvals, exception handling and reporting into a controlled invoice workflow alongside an ERP. It does not replace the buyer’s responsibility to define rules, integrations and ownership.

Read OCR is only the first step in invoice processing for a companion evaluation guide, or book free initial discovery to map one representative AP process.