Accounts payable exception handling: the process and the records it leaves

What is an accounts payable exception handling process?

An accounts payable exception handling process is the routine a finance team follows when an invoice cannot be approved and paid automatically. The invoice is flagged, routed to someone who can explain the gap, investigated with purchasing, receiving or the vendor, resolved with a documented decision, and only then released for payment or rejected.

Most mid-sized companies run some version of these seven steps, whether in an AP automation tool, an ERP workflow or a shared mailbox:

1. Capture. The invoice arrives by email, vendor portal or post and is keyed or scanned into the AP system.
2. Match. The system compares invoice lines with the purchase order (two-way match) and, for goods, with the receiving report as well (three-way match), within tolerance thresholds the controller has set.
3. Flag. Anything outside tolerance, missing a PO, duplicated or tied to changed vendor details lands in an exception queue with a reason code.
4. Route. The exception goes to the buyer, budget owner, receiving clerk or AP specialist who can resolve it, under the company's delegation of authority.
5. Investigate. That person checks the contract price, confirms what was received or queries the vendor, usually by email or in a comment thread.
6. Decide. The outcome comes from a short list: approve the variance, request a credit memo, short-pay, amend the PO, reject as a duplicate, or hold for vendor verification.
7. Record and close. The resolution, approver and date are logged, the invoice is paid or cancelled, and the reason code feeds month-end reporting.

The rest of this page looks at the trail those steps leave behind, and why that trail matters to AI developers.

Common AP exceptions and what each record shows

Each exception type produces a slightly different record. The valuable ones capture the problem, the people involved and the final decision.

Why AI developers value AP exception records

AI developers are building agents that carry out multi-step office work, and AP work has exactly that shape: read a document, compare it with two others, ask a colleague, apply a policy, decide, write down why. An invoice that matched automatically shows almost none of that. An exception shows all of it, with a known outcome at the end.

That structure makes exception history useful in two ways. For training, each resolved exception is a worked example of judgment applied to messy inputs. For evaluation, a past exception with a recorded decision becomes a test case: given the same invoice, PO, receipt and emails, does the agent reach the decision the controller actually made?

Records like these almost never appear on the public web. Researchers at Epoch AI project that, if current trends continue, language models could fully use the stock of public human-written text sometime between 2026 and 2032. It is a forecast with wide uncertainty, but it helps explain why permissioned, non-public business records draw interest.

The strongest AP exception histories share a few traits:

• Reason codes applied consistently, so exceptions can be grouped and compared.
• Linked documents, with invoice, PO, receiving record and correspondence tied together.
• Named roles for who flagged, investigated and approved, even if names are later masked.
• Timestamps showing how long each step took.
• Policy context: the AP manual, tolerance thresholds and delegation-of-authority matrix in force at the time.
• Depth over years, including the periods before and after a system change.

Where AP exception records live

Exception history is rarely in one place. A CAS team that knows the client's close process can usually name every location in one conversation.

Departed staff mailboxes are a frequent gap; the guide to former employee mailboxes in Microsoft 365 covers how companies keep that history while cutting license cost.

Rights and privacy questions specific to AP records

AP records mix documents the company created with documents vendors sent it, so a rights review has to look at both.

• Employee-created material. Exception notes, approval comments, policies and close checklists written by staff as part of their jobs generally belong to the company. The US Copyright Office's circular on works made for hire explains that for work prepared by an employee within the scope of employment, the employer is the author and owner. Material written by contractors may not belong to the company unless it was assigned in writing.
• Vendor-authored documents. Invoices, statements and vendor emails came from outside parties, and supplier contracts may carry confidentiality terms on pricing. Counsel reviews these before anything is included.
• Sensitive fields. Bank account details, tax identification numbers and remittance information run through AP records, and some vendors are sole proprietors whose details are personal data. Employee expense reimbursements often pass through the same queue.
• Records processed for others. When an outsourced AP provider or a CAS firm processes invoices on behalf of its clients, those records belong to the clients. A CAS team cannot license client AP data; only the client company itself can.

De-identification and redaction requirements are agreed with the company before any work begins, and data is delivered only after an executed agreement and the company's authorization. This is general information, not legal, tax or financial advice. Confirm with your own counsel before acting.

How a CAS team can describe AP exception records without sharing them

A referral partner needs only a metadata-level description: which systems, how many years, whether exceptions carry reason codes and outcomes, and who can export. No invoices, vendor names, amounts or screenshots leave the client.

The client list screening worksheet for CAS teams helps rank which clients are worth that conversation in the first place.

Checklist: signs a client has deep AP exception history

Tick what you already know from the engagement. Three or more ticks in the first group is a reason to ask the owner.

Records

• Purchasing runs on POs with two- or three-way matching, not ad-hoc approvals
• Exceptions are logged with reason codes and resolutions rather than settled in hallway conversations
• Approval comments live in the ERP or AP tool rather than in personal inboxes
• A written AP manual and tolerance matrix exist, with older versions kept
• Records from systems retired during past migrations were archived and can still be opened

Company fit

• The business is based in the US and reached 50+ full-time employees at peak (contractors excluded)
• It has several years of documented operations behind it
• The AP records are the company's own, not invoices it processes for clients
• None of the data has already been licensed for AI training
• The owner, CEO, CFO or another authorized representative could sponsor a license

The company fit checker runs a preliminary, non-binding version of the fit questions with no contact details required, and the who qualifies page sets out the full baseline.

When to raise it with the client

The natural moments are when AP history is already on the table: an auditor's request for invoice samples, an AP automation rollout, an ERP migration, or year-end planning. The page on year-end tax planning meetings shows how to fit one question about records into a meeting that is already booked. Raise it with the owner rather than the AP clerk, and ask permission before making any introduction.

Next step

If a client's AP history passes the checklist and the owner wants to explore it, register as a partner and make the introduction, or have the owner apply directly at sourcex.si/apply through your referral link. Fractional CFOs will find role-specific guidance in referral opportunities for fractional CFOs.