Accounts payable automation: resolve exceptions before payment

An invoice file, an invoice record, an approved liability, and a completed payment are different objects. I would give each a distinct identity and state. That prevents the system from reporting progress it has not actually achieved.

The incoming document record should retain its source, received time, supplier association, and file reference. Extraction produces proposed fields. Validation checks those fields. Review resolves exceptions. Only the approved downstream process can authorize payment.

For a first release, I would stop before payment execution. The deliverable is a dependable queue of matched records and clearly explained exceptions. That scope can remove administrative work while preserving the finance team's existing authority.

The implementation needs the organization's definition of a match. That may involve a purchase order, receipt record, supplier identifier, currency, quantity, tax treatment, and total. The rule should be explicit about tolerances and missing evidence.

If the invoice total differs from the purchase order, the queue should show the actual fields and the applicable rule. A generic “mismatch” label forces the reviewer to reconstruct the comparison. A useful exception says which line differs and links to both sources.

The model can help associate an invoice description with a purchasing line, but uncertain associations should remain suggestions. Do not use a plausible description match to bypass a missing receipt or an unapproved order. The finance owner decides which evidence is required.

A request to change supplier payment details should not be processed as an ordinary invoice extraction. I would route it through the organization's established verification procedure and keep it outside the model's authority.

The same applies when a familiar supplier sends from a new address or attaches a different account reference. The workflow can flag the difference and preserve the message. It should not update the supplier master because the email sounds convincing.

External invoice text is untrusted input. OWASP's prompt injection guidance describes how instructions embedded in external content can affect LLM behavior. I would ensure the extraction component cannot approve invoices, alter supplier records, or grant itself access even if the document contains such instructions.

A supplier may resend an invoice, or the inbox connector may deliver the same event twice. The workflow needs to distinguish repeated receipt from a new financial record. Use stable source identifiers and a finance-approved duplicate-detection rule rather than relying only on filenames.

Potential duplicates should be reviewable. Two invoices can share an amount and date without being the same invoice. Conversely, the same invoice can arrive as a differently named attachment. The system should show the evidence behind the flag and preserve both receipt events.

When writing to the accounting system, record the destination identifier. If the write times out, inspect the destination before replaying the operation. A retry that creates a second invoice record can be more expensive to repair than the original connector failure.

I would group exceptions by the person and action required: missing purchase order, receipt confirmation, supplier clarification, amount discrepancy, suspected duplicate, or unreadable document. The categories should reflect the team's actual responsibilities.

Every item needs a named owner or an explicit unassigned state. A queue with hundreds of “pending” records is not a managed process. Show the last action, missing evidence, and age of the exception so staff can decide what to handle next.

When a reviewer resolves an issue, capture the reason and the evidence used. If the resolution changes a field, preserve the earlier extracted value. That history helps distinguish extraction errors from supplier errors and from changes made during review.

Approval and synchronization should be separate. If finance approves a record but the accounting API is unavailable, the record should remain approved and awaiting write. The system should not require a new business approval simply because it must retry a technical operation.

However, if the underlying invoice changes, the approval may no longer apply. Bind approval to a specific record revision and verify that revision before writing. A corrected supplier invoice should trigger the appropriate review rather than inheriting approval from an earlier version.

For payment-related systems that use Stripe, Stripe's idempotency documentation illustrates one provider's repeat-request protection. An accounting connector needs its own verified contract; copying the word “idempotent” into a runbook does not create that protection.

I would use synthetic invoices with duplicate identifiers, alternate currencies, missing purchase orders, line-total discrepancies, and a supplier detail-change request. Include an API timeout after a successful write and a reviewer editing the record during synchronization.

For each case, verify the resulting accounting state, not just the workflow's final status. The test should show whether a record was created once, held for review, or left awaiting recovery. No test should create real payments unless the organization explicitly authorizes that separate activity.

Measure extraction correction rate, exception age, duplicate records prevented or created, review effort, and time to reconcile failed writes. Keep payment performance and working-capital claims out of the report unless the finance team has measured them.

The implementation should include field definitions, matching rules, reviewer permissions, duplicate handling, and a recovery queue. Finance should be able to explain why an item is held and what evidence will release it.

I would expand the workflow only after the team can operate that first scope. Adding automated payment execution is a separate decision with a different consequence. The initial goal is an accurate, reviewable handoff from incoming document to approved accounting record.

My acceptance scenario would use a synthetic invoice whose accounting-system write succeeds while the connector response is deliberately interrupted. The local workflow should mark the outcome unknown and retain the operation reference. A recovery attempt should locate the existing destination record rather than create another one.

Next, I would submit the same invoice through a second intake channel with a different filename. The system should preserve the second receipt and flag the possible duplicate using the configured business rule. The reviewer should see the earlier destination identifier and the evidence behind the match.

Finally, I would change the amount on a revised invoice. The implementation should not silently reuse the earlier approval or overwrite the existing financial record. It should route the revision through the finance team's correction process. These tests reveal whether the workflow understands the lifecycle of an invoice rather than merely the shape of its extracted fields.