AP Invoice Agent

Accounts payable is the last large finance workflow most companies still run entirely by hand. Someone opens the email, reads the invoice, checks the tax arithmetic, decides which GL account it belongs to, works out the withholding, and types it into the ERP. Several hundred times a month. It is slow, it is where coding errors and duplicate payments originate, and it is almost entirely rule-governed — which makes it the single best candidate for automation in the finance function, provided the automation can be trusted near the ledger.

How we build near a ledger

These five principles hold on every deployment. They are the reason a finance team signs off on this.

• —Drafts only. The system creates draft A/P invoices. Nothing posts to the ledger until a person reviews and releases it.
• —Human in the loop. Every automated decision, from the fields read off an invoice to the GL account chosen, is shown to a reviewer with its supporting evidence before anything is released.
• —Rules first, AI where it helps. Deterministic rules handle validation and posting logic. AI is used to read invoices and classify expenses, and anything it cannot read or classify with confidence is routed to a person rather than guessed.
• —Full audit trail. Each invoice is traceable end to end: received, extracted, validated, reviewed, and released, with the source email and document retained.
• —Secured handling. Invoice data and system credentials are held on secured infrastructure with restricted, role-based access.

What it does

The agent watches your AP mailbox and takes each invoice through the same sequence.

Captures it. The invoice is pulled from its source email, with sender, subject, and date recorded for the audit trail.

Reads it — including the formats that defeat most tools. Vendor and buyer tax registration numbers, invoice number and date, line items, product and service classification codes, taxable values, and the full tax breakdown, extracted into structured data. This is the part that quietly fails elsewhere: scanned PDFs with no text layer, Word documents, electronically signed PDFs — read without manual intervention.

Validates it against twelve checks. Tax registration number format. The correct tax split, derived from the registered jurisdiction codes on both sides rather than trusted from the face of the invoice. Tax arithmetic recomputed line by line. Totals footing. Product or service classification code present. Invoice dated inside an open accounting period. And the e-invoice conditional — where a statutory e-invoice identifier is present, the signature requirement changes accordingly. Each check records a pass, a warning, or a failure, with the evidence behind it.

Codes it. The GL account and the withholding-tax treatment are selected from your own mapping — the one your accounting team maintains, not one a model invented — and the correct ERP tax code is derived from it.

Checks it against what governs it. The invoice is compared against its service PO, contract, fee schedule, or lease deed, and matches and variances are reported. This is handled by our Document Intelligence Agent, which reads long scanned agreements and cites its findings back to the page they came from.

Drafts it in your ERP. A draft A/P invoice is created through the SAP Business One Service Layer, with a live document reference returned — a real document in your company database, waiting for release.

Hands it to a person. Everything above arrives in a reviewer application as a single card: the source document alongside every extracted field, each check and its result, the GL and withholding decision with its reasoning, the contract comparison, and the draft reference. The reviewer releases or rejects. The audit trail records who did which, and when.

Statutory logic, not model guesswork

Tax treatment, withholding rules, e-invoicing requirements, place-of-supply logic — these vary by jurisdiction and change over time, and getting them wrong is expensive. The statutory logic in our finance agents is written against current rules and your own mapping, with senior finance and compliance advisory input, rather than inferred by a model. Where treatment is genuinely ambiguous, the invoice routes to your reviewer instead of being decided automatically.

Where it extends

The service-invoice pipeline described above is what we deploy first, because service invoices post standalone and the path to value is shortest. Material invoices work differently and are handled as a following phase: the A/P invoice is created by copying from the Goods Receipt PO and matched against the purchase order rather than entered on its own, with supplier part numbers mapped to your item master. Imports add landed cost, customs valuation, exchange-rate handling, and reconciliation to the customs entry. Same pipeline, same reviewer, same audit trail — additional matching logic.

What it needs

• —An ERP that exposes an API. SAP Business One via the Service Layer is what we've built against; others by arrangement.
• —A dedicated integration user with a valid named-user license. SAP B1 is licensed per named user and the Service Layer will not authenticate without one — worth confirming early, as it's the most commonly forgotten item.
• —The CompanyDB name, and network access to reach the Service Layer, by VPN or IP allowlisting.
• —Mailbox access for the AP inbox (Microsoft Graph consent for the designated mailboxes).
• —Your GL mapping baseline, vendor master, and tax-code list, as your accounting team maintains them.
• —A designated per-vendor location for contracts and service POs, kept populated.
• —A test company database to build against. A posted A/P invoice cannot be deleted in SAP B1, only cancelled — so no build work should ever touch the live company.
• —Finance-team availability for user acceptance testing and sign-off.

What the output looks like

A reviewer opens one screen and sees the day's invoices as cards. Each card puts the source document beside the extraction, so nothing has to be taken on trust: every field carries the check that validated it, every exception is stated with the evidence that raised it, and the GL and withholding decision shows the mapping row it came from. Where a governing contract or PO exists, its relevant terms sit alongside the invoice with variances flagged. At the bottom of each card is the draft's document reference in your ERP. Release, and the draft is ready for posting; reject, and it routes back with a note. Nothing moves without that click.

How this gets delivered

This is an enterprise implementation, not a subscription switch-on. We start with a discovery conversation, then a proof of concept run against a batch of your own real invoices — which is how you find out whether this works on your documents before committing to a build. The production phase follows: 2.5 to 3.5 months to a live first phase, then UAT, sign-off, handover, and ongoing maintenance covering extraction accuracy, mapping changes, and statutory updates such as tax-rate changes and withholding-threshold revisions.