Automating accounts payable: invoice capture, routing, and controls

Reference article · 6 min read

Accounts payable is one of the few back office functions made almost entirely of documents moving between people. An invoice arrives, someone decides what it paid for, someone confirms the goods or services were received, someone with authority approves it, and a payment file goes to the bank. Every step is a handoff, and handoffs are where invoices sit. When volume grows faster than staffing, the queue gets longer at exactly those points.

Automation is a good fit for most of that, because the mechanical parts are genuinely mechanical: reading a number off an image, matching it to a purchase order, sending it to the right approver, and reminding that approver twice. But part of AP work should stay slow and human on purpose. The costliest failure in a payables operation is usually not a late invoice. It is a payment routed to a bank account that a fraudster supplied. Keep that verification outside the automated path, no matter how good the rest of the system is.

What automation actually removes

The realistic gains are in transcription, movement, and retrieval: keying header and line data from invoice images, deciding where an invoice goes next, chasing approvers, filing paper, finding a document when a vendor calls, and flagging likely duplicates before they pay twice.

What it does not remove is judgment. Someone still decides whether a cost is allowable on a grant, whether the work was actually received, whether a vendor is legitimate, and how to settle a disputed line. If a product is pitched as eliminating those, read it as a claim about the vendor's understanding of public finance rather than a description of your workload.

Invoice intake and coding

Consolidate intake before you automate it. A dedicated AP address, a vendor portal upload, and a scanning path for mail should cover everything, so invoices stop arriving in individual program managers' inboxes where they age invisibly.

• Capture with confidence thresholds. Extraction should report how sure it is per field and route low confidence fields to a person instead of silently guessing.
• Coding suggestions, human confirmation. Systems that suggest fund, department, and object codes from payment history are useful. Require explicit confirmation for grant funded, capital, and new vendor invoices, where a wrong code is expensive to unwind.
• Duplicate detection. Check vendor plus invoice number plus amount, and also near matches such as an invoice number with a changed prefix.
• PO and non PO paths. Define matching tolerances for PO backed invoices and a separate rule for who may approve a non PO invoice, since that is where most exceptions live.

Approval routing tied to delegated authority

Build routing from your delegation of authority policy, not from the workflow template the vendor ships. Write the policy out as rules first: dollar thresholds, department and fund ownership, an added approver for grant funded costs, and any board or council action required above a level.

• Absence delegation with a record. Approvers take leave. The system should support time bounded delegation that records who actually approved, not a shared login.
• Separation of duties. A person who can approve a payment should not also be able to edit the vendor master or banking details.
• Aging and escalation. Automatic reminders and escalation after a set period, plus a report showing which approvers hold the most invoices, are often the largest single reduction in cycle time.
• Prompt payment. Many states impose payment timeframes and interest on late payment by public agencies, and terms vary widely. Confirm your state's current requirements with the statute or your counsel rather than with a vendor's marketing material.

Exceptions, and measuring the right things

Name your exception types explicitly: no purchase order, price variance, quantity variance, missing receipt, expired contract, unregistered vendor, missing W-9. Give each an owner and a target response time.

Then measure causes, not just volume. Track the share of invoices that post without human touch, aging by exception type, and which departments generate the most exceptions. Most recurring exceptions have an upstream fix, usually receiving that is never entered or contracts that lapse while spending continues.

Vendor self-service and bank detail changes

A vendor portal that shows invoice status and accepts W-9 uploads reduces phone calls. It also widens the attack surface, because it gives an outsider a place to submit changes. Treat banking and remittance changes as a separate, deliberately manual control:

• Out of band callback. Verify by calling a number already in the vendor file from an earlier verified source, never a number or address supplied in the change request itself.
• Dual control. One person enters the change, a second approves it, and the system records both.
• Notice and delay. Notify the previously known vendor contact of the change, and consider a prenote or short hold before the first payment to a new account.
• Monitoring. Review a vendor change report on a schedule, alert on banking and address edits, and compare vendor bank details against employee accounts.
• Urgency is a signal. Pressure to bypass verification is the most common feature of these frauds.

Positive pay and ACH debit filters with your bank belong in the same control set.

Year end and 1099 preparation

Most 1099 pain is created months earlier. Collect the W-9 at vendor onboarding and block payment without one. Use the IRS TIN matching service to catch name and number mismatches while there is time to fix them. Classify payment types at the object code level, so reportable status is a data attribute rather than something reconstructed from memory in January. Reconcile the reporting extract against payment history before filing. Reporting thresholds, form assignments, and electronic filing rules change, so confirm the current year's IRS instructions rather than repeating last year's process.

What to ask before you buy

• What exactly counts as touchless in your reporting, and what human steps are excluded from that count?
• How is pricing structured, per invoice, per user, or subscription, and what happens as volume grows?
• Do you charge our vendors anything for enrollment, for faster payment, or through card rebates, and who receives any rebate?
• Can we export all images, extracted data, and audit trails in bulk, in a documented format, during the term and at exit?
• Can routing model our delegation policy, including thresholds, grant approvers, and time bounded absence delegation?
• How are vendor master and banking changes controlled, and can dual approval be enforced in the system rather than by policy alone?
• What independent security assessment can you provide, and where is our data stored?
• Can records be retained and disposed under our retention schedule, and can we apply a legal hold?
• What accessibility conformance documentation do you provide for the vendor portal and staff screens?

Put the export right, the audit trail requirements, and any limits on fees charged to your vendors in the contract, not in the proposal.

HQT works with state and local agencies on back office systems integration, workflow design, and the controls that sit around financial applications.

Frequently asked questions