By the Foxnut team · Updated
Definition
Accounts payable, from invoice capture to payment run
What makes an AP invoice an exception, what a wrong payment costs and who absorbs it, whether it can be undone, and where this page's territory ends and the matching control's begins.
By the Foxnut team · Updated
What accounts payable covers, and where it stops
An invoice arrives. Before it becomes a payment, four things happen to it: it is captured, so a system has the data rather than a document; it is coded, so a general ledger account and a cost centre carry the charge; it is routed for approval, so somebody with the authority to spend has said yes; and, on a schedule set by terms rather than by convenience, it is paid. Each of those four steps has its own way of going wrong, its own owner, and its own automatable core, and none of the four is a question of whether the invoice matches a purchase order or a goods receipt. That comparison is a separate, later control with its own page, and this one does not repeat it: what a payables system’s new owner receives covers the handover for everything below, which is the standard worth reading before any of these four steps gets a vendor in the room.
The reason to treat the four as one process rather than four separate automations is that they share an input problem. A “proper invoice”, in the sense the United States government’s own payment regulation defines it, has to correctly carry ten specific items: the vendor’s name, an invoice date, a contract or other authorisation reference, the vendor’s own invoice number, a description with price and quantity, shipping and payment terms, a taxpayer identifying number, banking information, a contact, and any other documentation the contract requires. An invoice missing any one of those ten is not a matching failure and not a coding failure specifically; it is incomplete at the point of capture, and everything downstream inherits the gap. The same regulation gives the plainest possible statement of what an agency is required to do about it: when an invoice is found improper, it goes back to the vendor as soon as practicable, no later than seven days after receipt, with every defect that prevents payment identified at once, not discovered one round at a time.
The four stages, and what each one actually decides
| Stage | What it decides | Where it commonly breaks |
|---|---|---|
| Capture | Whether the ten fields a proper invoice needs exist as data at all, not as an image | A field is present on the paper and absent from the extraction, or present and wrong, and nothing downstream can tell the difference between “missing” and “wrongly read” without a human eye |
| Coding | Which general ledger account and cost centre the charge belongs to | The invoice description is written for the vendor’s own catalogue, not the buyer’s chart of accounts, so the mapping is inference rather than lookup |
| Approval routing | Who has to say yes before money is committed, and at what threshold | The threshold is set once and never revisited, so a routing table built for last year’s spend pattern silently over- or under-escalates this year’s |
| Payment run | When, how and in what amount the vendor is actually paid | The run executes against whatever coding and approval already decided, so an error caught here is an error caught last, not caught first |
Capture and coding are where an AI system does the most defensible work, because the ten-field checklist above is exactly the kind of fixed, enumerable target that extraction and classification are measured against elsewhere in this pillar. Approval routing is policy wearing the clothes of automation: a routing table is a set of rules a business already has opinions about, and encoding it is not the same kind of problem as reading a scanned document. The payment run is where the stakes change, because it is the one stage whose output leaves the business.
Where this page ends, and the match begins
Somewhere between coding and approval, most accounts payable processes also ask whether the invoice agrees with what was ordered and what arrived. That comparison, and everything that happens to an item it holds back, is the boundary this page keeps with the matching control: how tight the agreement has to be before an item passes, how a held item is sorted and reasoned about, and who is allowed to release one, are all decided on the other side of that fence. What this page adds on its own side is simpler to state than to build: a system that gets an invoice into clean data, codes it consistently, and routes it to the right approver has done real work whether or not anything on the far side of that fence ever runs.
What the decision turns on
Six structural dimensions decide whether a process is worth automating. Accounts payable reads unevenly across them, because three of the four stages it owns produce almost no lasting record of their own mistakes, and the fourth, the payment run, produces one that is very hard to take back.
| Dimension | What it reads on accounts payable | Source |
|---|---|---|
| Exception variance | Defined by a checklist, not by judgment. A proper invoice has to correctly carry ten specific items, from the vendor's name and an authorisation reference through to banking information and a contact; missing or wrong on any one of the ten makes the invoice improper, full stop, and the regulation that defines the checklist also requires the improper invoice to be returned within seven days with every defect named at once. That gives a clean, countable definition of the exception population before any approval or payment step is reached: it is whatever fraction of arriving invoices fails a fixed, known checklist, which is knowable by counting rather than by estimating. | 5 CFR 1315.9(b)(1), 1315.4(c)(2) |
| Volume | Not a payback threshold, because none is publicly sourceable, but a real number exists in how at least one vendor prices the capture step. One Dynamics 365 Finance feature is licensed by the transaction: a tenant gets 100 invoice-capture transactions a month before it must buy additional capacity at 300 US dollars per 1,000 transactions a month. That is a statement about where the vendor expects casual, low-volume use to end, not a statement about when automating pays for itself - the two are different claims, and only the first is sourced here. The honest volume question is the number of distinct vendors, formats and approval paths a business's invoice population actually contains, since that is what makes capture and coding hard, not the raw count of invoices. | Microsoft, Dynamics 365 Finance, 'Invoice capture solution overview' |
| Cost of an error | Priced two different ways depending on which of the four stages fails. A late payment is priced automatically and without argument: federal contracting rules pay an interest penalty on a late invoice without regard to whether the vendor even asked for it, drawn from the paying program's own funds, with no separate appropriation available to cover it - lateness has a built-in, non-discretionary cost. A wrong payment is priced by who is on the inside of the process: in a 2026 study of 2,402 occupational fraud cases, schemes in which an employee intercepted, forged or altered an outgoing check or electronic payment, including re-routing a payment to a vendor into the employee's own account, numbered 243 cases, 10% of the total, with a median loss of USD 114,000, a median 13 months before detection and a median velocity of USD 8,800 lost for every month the scheme continued. | 5 CFR 1315.10(b); ACFE, Report to the Nations 2026 |
| Reversibility | High before the payment run, low and bank-mediated after it. Nothing about a captured, coded or routed invoice is hard to correct - it is a record in a system, and re-keying, re-coding or re-routing it changes nothing outside the business. A payment order is a different object under commercial law: it can be freely cancelled or amended before the receiving bank accepts it, but afterward cancellation is not effective unless the receiving bank agrees or a funds-transfer system rule allows it without agreement, and the beneficiary's own bank may only claw money back in narrow cases - an unauthorised order, or the sender's own duplicate, wrong-beneficiary or excessive-amount error. The window that matters operationally is therefore not inside the business at all; it is however long it takes another bank to agree. | UCC 4A-211 |
| Regulatory exposure | Attaches to coding and to authorisation specifically, for any issuer. Securities law requires an issuer to keep books, records and accounts that, in reasonable detail, accurately and fairly reflect its transactions - which is exactly what an AP coding decision produces - and separately requires a system of internal accounting controls giving reasonable assurance that transactions are executed in accordance with management's authorisation. Approval routing is the mechanical expression of that second requirement: a routing table is, in the regulator's own terms, how a business demonstrates that a payment left only because someone with the authority to approve it did. | 15 U.S.C. 78m(b)(2)(A), (B) |
| Vendor market maturity | Settled enough to ship a human into the workflow on purpose. At least one major ERP's own invoice-capture documentation names a required role, an AP clerk, whose stated job is to review and correct what the OCR layer captured, and separately notes that a fully touchless flow needs an extra role grant, naming touchless processing as a distinct, deliberately configured case rather than the default behaviour. The same documentation prices the capability by the transaction, with a metered free allowance before further use is purchased in blocks. A market that ships review as the default and touchless as an add-on, and that meters usage rather than selling a flat licence, is one that has not yet decided capture is a solved problem. | Microsoft, Dynamics 365 Finance, 'Invoice capture solution overview' |
The exception and regulatory rows point at the same design choice from different directions. The exception row says the standard case is enumerable - ten fields, present and correct - so a system can be confident about what it has captured cleanly and honest about what it has not. The regulatory row says the two things that carry legal weight, the coding and the authorisation, are exactly the two things a checklist-driven capture layer does not itself decide. Automating the capture does not automate the accountability; it only clears the desk so a person’s coding and approval decisions are the ones actually being reviewed.
Accounts payable: the studio’s position
Two claims on this page need to be read with more care than the rest of it. Both trace to one source only, the founder’s own account of the studio’s engagement history: an operating record, not a cited market statistic.
Named directly
The studio has built accounting and finance automation for a client, and the engagement's own account of what it touched names paying suppliers directly, alongside daily reconciliation, accounts receivable, bank reconciliation, invoice reconciliation and tax reconciliation
Not in isolation
The founder's stated view, given as the studio's position rather than a finding: that finance automation is very hard to build one process at a time, because it touches all the different parameters and subsystems that make up a company's finance function
| Number | What it measures | Period | Source |
|---|---|---|---|
| Named directly | The studio has built accounting and finance automation for a client, and the engagement's own account of what it touched names paying suppliers directly, alongside daily reconciliation, accounts receivable, bank reconciliation, invoice reconciliation and tax reconciliation | As of August 2026 | Foxnut Studios engagement records (not externally retrievable) |
| Not in isolation | The founder's stated view, given as the studio's position rather than a finding: that finance automation is very hard to build one process at a time, because it touches all the different parameters and subsystems that make up a company's finance function | As of August 2026 | Foxnut Studios engagement records (not externally retrievable) |
The “Named directly” record states which processes the engagement reached, nothing more - not how it went, how well it worked, or what it cost. The “Not in isolation” record is a view, not a finding: a position taken from that same operating record. Everything else - exception counts, build time, cost, who ran it, which client - stays unstated, because the founder did not supply it and this page does not infer it.
What this usually gets wrong
The first error is treating a high capture accuracy rate as proof the process is done. Extracting ten fields correctly from a scanned invoice is a real, measurable win, and it says nothing about whether the coding is right or whether the routing sent the invoice to someone who should have said no. A dashboard that reports touchless-processing rate and stops there is reporting the easy half.
The second error is setting the approval-routing thresholds once and treating them as infrastructure rather than as a policy a business still has to own. A threshold that made sense at last year’s spend level quietly stops matching this year’s, and nothing about an automated router notices that on its own; only a person re-reading the routing table does.
The third error is discovering a coding or capture mistake at the payment run, which is the worst place to discover it. By the time a payment order exists, the correction options are worse: recall depends on another bank’s cooperation rather than on anything the business controls, and a check-or-payment-tampering scheme that has already re-routed the money is, on the evidence above, running for a median of thirteen months before anyone notices. Review belongs at capture and coding, where a mistake is still just a record.
The fourth error is confusing the case for touchless capture with a case for touchless payment. The evidence for automating extraction is that the target is fixed and enumerable, ten known fields. Nothing about the payment run has that shape: it is the one stage whose error is expensive, slow to detect and hard to reverse, and it is the stage where a named review step, not a higher automation percentage, is the thing actually worth building toward.
The verdict
The evidence supports automating capture and coding aggressively, routing approvals by rule with the thresholds reviewed on a schedule rather than set once, and keeping a named person in the loop specifically around the payment run rather than around the process as a whole.
The first half follows from the exception and maturity rows together: a ten-field checklist is exactly the shape of target current capture tooling is built to hit, and at least one shipped product already assumes a human reviews what it extracts, which is the safe default to keep rather than to engineer away. The second half follows from the cost-of-error and reversibility rows: a coding mistake is a record that can be corrected for the price of correcting a record, while a payment that has left the business depends on another bank’s agreement to come back, and the fraud evidence says the exact failure mode this stage is exposed to, an employee altering an outgoing payment, runs undetected for over a year on average when nobody is specifically watching for it.
For a team weighing this, the count that matters is not invoice volume. It is how many of the last quarter’s invoices failed the ten-field checklist above, how many were coded and later recoded, and how many payment orders were cancelled or contested after the fact. Those three counts describe the actual state of a payables process better than any vendor’s demo does. Share those three counts and the honest answer about which of the four stages is worth automating first comes back specific to that process, not generic to the pillar.
Sources
- 5 CFR part 1315 (Prompt Payment), Office of Management and Budget - section 1315.9(b)(1)'s ten items of correct information that constitute a proper invoice (vendor name, invoice date, contract or other authorisation number, vendor invoice number, description/price/quantity, shipping and payment terms, taxpayer identifying number, banking information, contact details, other substantiating documentation); section 1315.4(c)(2)'s requirement that an agency return an improper invoice to the vendor as soon as practicable, no later than 7 days after receipt, identifying all defects that prevent payment; section 1315.2(d)'s definition of the applicable interest rate as the rate the Secretary of the Treasury establishes under the Contract Disputes Act, published semiannually and also called the Prompt Payment Act Interest Rate; and section 1315.10(b)'s requirement that late payment interest penalties be paid without regard to whether the vendor requested them, from the program's own funds, with no separate appropriation authorised for the purpose. Read as the eCFR enhanced-content rendering of the current part Retrieved
- Securities Exchange Act of 1934, section 13(b)(2), 15 U.S.C. 78m(b)(2)(A) and (B) - the books-and-records requirement that an issuer make and keep records which, in reasonable detail, accurately and fairly reflect its transactions, and the internal-accounting-controls requirement that a system provide reasonable assurance that transactions are executed in accordance with management's general or specific authorisation and are recorded as necessary to permit financial statements in conformity with generally accepted accounting principles and to maintain accountability for assets. Read via Cornell Law School's Legal Information Institute Retrieved
- Uniform Commercial Code section 4A-211, 'Cancellation and Amendment of Payment Order', official text - the rule that a payment order can be cancelled or amended before acceptance on reasonable notice to the receiving bank, that cancellation or amendment after acceptance is not effective unless the receiving bank agrees or a funds-transfer system rule permits it without agreement, the beneficiary's bank's narrow right to reverse a payment and recover from the beneficiary where the order was unauthorised or resulted from the sender's own duplicate, wrong-beneficiary or excessive-amount error, and the automatic cancellation of an unaccepted order at the close of the fifth funds-transfer business day after its execution or payment date. Read via Cornell Law School's Legal Information Institute Retrieved
- Association of Certified Fraud Examiners, 'Occupational Fraud 2026: A Report to the Nations' - the glossary definition of a check or payment tampering scheme as a fraudulent disbursement scheme in which a person steals an employer's funds by intercepting, forging or altering a check or electronic payment drawn on the organisation's own bank accounts, including an employee re-routing an outgoing electronic payment to a vendor into their own account; figure 5's table (check and payment tampering: 243 cases, 10% of all cases, USD 114,000 median loss); figure 8 (13 months median duration to detection); and figure 9 (USD 8,800 median loss per month the scheme continued undetected). Read as text extracted from the association's own report PDF Retrieved
- Microsoft, 'Invoice capture solution overview', Dynamics 365 Finance product documentation - the required-roles table naming an AP clerk role whose stated action is to 'review and correct captured invoices in Invoice capture'; the note that a flow user must additionally be granted the InvoiceCaptureOperator role 'for a touchless scenario', naming touchless processing as a distinct, separately configured case rather than the default; and the licensing FAQ's entitlement of 100 invoice capture transactions per tenant per month before a customer must purchase additional Electronic Invoicing capacity at 300 US dollars per 1,000 transactions per tenant per month Retrieved
Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is how an AI engagement is scoped and priced.