Skip to main content
Concept #130

AI in Accounts Payable

How intelligent invoice processing can accelerate AP without surrendering control of the cash—AI may prepare an invoice for payment, but it should not invent the evidence that authorizes it.

Educational content — not software-selection advice or a substitute for your organization's control design. Vendor product capabilities (including Microsoft invoice processing and Dynamics invoice capture) describe what a tool can do—not universal performance for every invoice, layout, or implementation. Organization-specific accuracy figures on this page (for example, an 88% coding case study or a 76% touchless deployment) stay labeled as such and are not treated as industry benchmarks.

The Central Lesson

Artificial intelligence can read invoices, extract fields, suggest coding, compare invoices with purchase orders and receipts, identify unusual transactions, and route exceptions to the right person. It cannot prove that an invoice represents a real obligation, that a new bank account belongs to the vendor, or that payment should be released.

In accounts payable, the right goal is therefore controlled automation: let software process predictable work while people investigate exceptions and retain authority over vendors, approvals, and cash.

Remember this line

AI may prepare an invoice for payment. It should not be allowed to invent the evidence that authorizes payment.

Learning objectives

  • Explain where AI fits within the procure-to-pay process.
  • Distinguish extraction, prediction, validation, approval, and payment authorization.
  • Describe two-way, three-way, and four-way matching.
  • Identify duplicate invoices and vendor-payment fraud indicators.
  • Design human-review thresholds and exception queues.
  • Evaluate AI performance using field-level and business-level measures.
  • Protect vendor-master changes and preserve segregation of duties.
  • Review an AI-assisted AP transaction from source document to general ledger.

AP Before AI

Accounts payable records amounts a business owes suppliers for goods and services already received but not yet paid. A typical process begins when the organization receives an invoice and ends when an authorized payment is released, recorded, and reconciled.

For a purchase-order invoice, the evidence may include:

Purchase order

What the organization authorized.

Receiving record

What the organization actually received.

Vendor invoice

What the supplier billed.

Approval record

Who accepted the charge or exception.

Payment record

What the organization ultimately paid.

General-ledger entry

How the obligation and payment were recorded.

These documents perform different jobs. An invoice is a request for payment; it is not, by itself, proof that the purchase was authorized, the goods arrived, or the payment instructions are legitimate.

Where AI Fits

AI-assisted AP is best understood as a pipeline rather than a single button.

StageWhat technology can doWhat still requires control
IntakeMonitor an AP mailbox, recognize attachments, and create a work itemRestrict approved intake channels and preserve the original document
ExtractionRead vendor name, invoice number, dates, amounts, taxes, purchase-order references, and line itemsCompare extracted values with the source and route low-confidence fields for review
ClassificationSuggest a vendor, account, cost center, department, project, or tax codeApply company policy and verify unusual or material coding
MatchingCompare invoice data with purchase orders and receiving recordsDefine tolerances and investigate mismatches rather than forcing a match
Duplicate detectionCompare vendor, invoice number, date, and amount; use fuzzy matching to find near-duplicatesDetermine whether the candidate is a duplicate, installment, recurring invoice, credit, or valid resubmission
Approval routingSend invoices and exceptions to designated approversEnforce approval authority and prevent self-approval
Fraud screeningFlag unusual bank changes, domains, amounts, timing, or vendor behaviorIndependently verify high-risk changes through a trusted channel
PostingPrepare a pending vendor invoice and proposed accounting entryRequire validation before posting and retain a traceable audit log
PaymentAssemble an approved payment batchKeep payment release separate from invoice preparation and vendor maintenance

Product capability — not a universal guarantee. Microsoft's published invoice-processing model extracts common fields such as invoice ID, invoice date, and amount due; custom document models can cover organization-specific fields and tables. Dynamics 365 documentation says captured invoices can be validated against rules before conversion into vendor invoices, while invoices with errors or warnings require manual review. These describe what the product can do—not evidence that every invoice, layout, vendor, or implementation will achieve the same performance.

AI Is Not One Thing

The phrase "AI in AP" often combines several technologies that have different error patterns.

Optical character recognition

OCR converts printed or handwritten characters in a document image into machine-readable text. OCR may correctly recognize a number but still attach it to the wrong field—for example, reading a purchase-order number as the invoice number.

Document understanding

Document-understanding models use text, layout, labels, and surrounding context to identify fields and tables. Peer-reviewed invoice research shows that invoice-layout populations matter: models may perform differently on familiar layouts than on invoices from new or infrequent suppliers.

Machine-learning classification

Classification models predict a category, such as an expense account or cost center, using historical examples. One 2021 master’s thesis based on a private Finnish organization reported that its best models could automate 88% of general-ledger account coding in that case study; that result is organization-specific and should not be treated as a universal benchmark.

Rules and workflow automation

Rules enforce explicit conditions such as “invoice total must equal line totals” or “bank changes require two approvals.” Workflow automation moves records, sends notifications, creates holds, and records decisions. These are often more deterministic and auditable than generative AI.

Generative AI

Generative AI can summarize invoice exceptions, draft vendor messages, explain differences, or help an AP employee search policies. Because generated language can be persuasive even when wrong, it should not be treated as documentary evidence, approval, or independent verification.

The Invoice Workflow

Capture the source

The system should retain the original invoice and record when, where, and from whom it was received. A strong workflow preserves the source document even after values are extracted or corrected.

Microsoft's documented reference architecture, for example, keeps original invoice files, validates invoice attributes before creating a pending ERP record, logs failures, and blocks incomplete invoices from entering the finance system. That is a useful architecture pattern, but any suggested service-level target in vendor materials is an implementation example—not an industry benchmark.

Extract the fields

At minimum, extraction normally attempts to identify:

  • Vendor identity
  • Invoice number
  • Invoice and due dates
  • Purchase-order number
  • Currency
  • Subtotal, tax, freight, and total
  • Line descriptions, quantities, and prices
  • Remittance information

Extraction quality must be measured by field. A system that reads vendor names correctly but frequently misreads totals is not safe merely because its average field accuracy appears high. NIST advises organizations to define realistic test sets, document test methods, examine false positives and false negatives, and determine whether performance generalizes beyond training conditions.

Validate the mathematics

Before matching, the workflow can perform deterministic checks:

  • Do line extensions equal quantity multiplied by unit price?
  • Do line amounts sum to the subtotal?
  • Does subtotal plus tax, freight, and other charges equal the invoice total?
  • Is the due date consistent with the invoice date and approved payment terms?
  • Is the currency valid for the vendor and legal entity?

A failed calculation does not prove fraud. It creates an exception requiring investigation.

Identify the vendor

Vendor recognition should connect the invoice to an approved vendor-master record rather than creating a new vendor simply because a name appears on a document. Variations in punctuation, abbreviations, addresses, and legal names make this a useful prediction task—but final vendor creation remains a controlled master-data event.

Match the evidence

Matching asks whether the invoice agrees with other business records.

MethodEvidence comparedWhat it tests
Two-way matchPurchase order and invoiceWhether billed quantity and price agree with what was ordered
Three-way matchPurchase order, receiving record, and invoiceWhether the organization was billed for goods recorded as received
Four-way matchPurchase order, receiving record, acceptance/inspection record, and invoiceWhether billed items were ordered, received, and accepted

Oracle's Payables documentation defines two-way matching as checking billed quantity and invoice price against the purchase order; three-way matching adds quantity received; four-way matching adds quantity accepted. The system can place an invoice on hold when matching criteria fail, but management must define tolerances appropriate to the transaction and risk.

Code the invoice

For non-purchase-order invoices, AI may suggest the account, department, location, project, or tax treatment from prior transactions and vendor history. A suggestion is not a conclusion. New vendors, unusual purchases, changing operations, one-time projects, and historically miscoded transactions can all make past patterns misleading.

Low-risk repeat invoice

Suggest and post only after defined checks pass.

Unusual coding

Route to an AP specialist or budget owner.

Policy-sensitive account

Require named approval regardless of confidence.

Material or novel transaction

Require source-based accounting analysis.

Approve, post, and pay

Approval confirms business authorization; posting records the liability; payment releases cash. Combining these steps under one person—or one uncontrolled automated identity—creates a serious control weakness. GAO describes segregation of duties as separating authorization, processing and recording, review, and custody of assets so that one person cannot both cause and conceal a misstatement.

Accounting Entries

Suppose ABC Coffee Shop receives and accepts $1,200 of equipment-maintenance services on credit.

When the invoice is recognized

AccountDebitCredit
Repairs and Maintenance Expense$1,200—
Accounts Payable—$1,200

When the approved invoice is paid

AccountDebitCredit
Accounts Payable$1,200—
Cash—$1,200

AI may extract "$1,200," identify the vendor, and suggest Repairs and Maintenance Expense. The accountant must still determine whether the service occurred, whether the expense belongs in the current period, whether it should instead be capitalized, whether the vendor is approved, and whether payment is authorized.

Worked Example: ABC Coffee Shop's Invoice Queue

ABC Coffee Shop uses AI to review five incoming invoices. The system has already extracted the fields and proposed an action.

InvoiceEvidenceAI resultProper human response
Coffee beans, $4,800PO, receipt, and invoice agree within policy“Ready to post”Verify the source links and approval, then allow normal processing
Espresso-machine parts, $2,140Invoice quantity is 12; receiving record shows 10“Match exception”Hold the invoice and investigate the quantity difference
Monthly rent, $6,000No PO by policy; approved lease and recurring schedule exist“No PO—reject”Override only after confirming the approved non-PO workflow and lease evidence
Packaging invoice, $980Same vendor and amount as a prior invoice; invoice number differs only by a leading zero“Possible duplicate”Compare source documents and payment history before rejecting or paying
Cleaning vendor, $3,250Email requests a new bank account and urgent payment“Vendor data updated”Freeze the change and independently call a previously verified vendor contact

The exercise shows why confidence and control are different. The coffee-bean invoice may be low risk because independent records agree. The rent invoice may be valid even though it does not fit a purchase-order model. The bank-change request is dangerous even if every invoice field was extracted perfectly.

Duplicate Detection

Exact duplicate rules are necessary but insufficient. A duplicate invoice can be resubmitted with punctuation removed, a leading zero added, a date shifted, or a credit recorded with the opposite sign.

The ACFE recommends testing at least vendor number, invoice number, invoice date, and invoice amount, then supplementing exact matches with carefully designed fuzzy matching. Candidate logic might include:

  • Same vendor + same invoice number + same amount.
  • Same vendor + normalized invoice number + same amount.
  • Same vendor + same amount + nearby invoice dates.
  • Same bank account used by multiple vendors.
  • Same invoice image or file hash submitted more than once.
  • Invoice and offsetting credit separated from the related transaction.

A duplicate flag is not proof of a duplicate. Recurring rent, installment billing, legitimate resubmissions, and standard-price purchases can look similar. The reviewer should record why the item was released, rejected, or escalated.

The Bank-Change Problem

Accounts payable is a direct route to cash, making vendor-payment changes especially sensitive. The FBI describes business email compromise as a scheme in which criminals compromise or imitate trusted email accounts to induce unauthorized transfers, including by impersonating a legitimate vendor and changing payment instructions.

For significant transfers and beneficiary-account changes, the FBI recommends secondary independent verification, two-factor authentication, and confirmation through a channel established outside the requesting email. The control implication is clear:

1

Place the invoice or payment change on hold.

2

Retrieve a previously verified telephone number from the vendor master, contract, or earlier independent record.

3

Call the known contact; do not use contact details supplied in the change request.

4

Require a second authorized person to approve the vendor-master change.

5

Record who verified it, when, by what channel, and what was confirmed.

6

Keep vendor maintenance separate from payment release.

AI may flag a lookalike domain or unusual account. It should never be the only party "confirming" that a bank account is legitimate.

AI Can Also Strengthen Fraud

AI can help identify anomalies, but it can also create convincing fake invoices, receipts, contracts, spreadsheets, bank statements, emails, voices, and images. The Journal of Accountancy warns that AI can make false supporting documents more realistic and advises obtaining evidence from reliable third-party sources and verifying AI outputs.

This creates an important hierarchy of evidence:

EvidenceRelative reliability
Record obtained directly from a bank, approved procurement system, or controlled receiving systemStronger
Original vendor document received through an established channelUseful but still subject to verification
Forwarded email, screenshot, or newly supplied contact informationWeaker
AI-generated summary or explanationNot source evidence

Appearance is not authenticity. A perfect-looking invoice may be false, while an ugly scanned invoice may represent a genuine obligation.

Measuring Performance

A responsible AP implementation needs more than a "touchless rate." One peer-reviewed deployment paper reported processing approximately 80,000 invoices for two clients, with 76% handled with low or no manual intervention. That is evidence from one deployed system—not a guaranteed result for other organizations.

Measure the system at several levels:

MeasureQuestion
Field exact-match rateWas each invoice field extracted correctly?
Critical-field error rateHow often were vendor, total, currency, PO, or bank fields wrong?
False-positive rateHow often did the system flag a valid invoice?
False-negative rateHow often did it miss a duplicate, mismatch, or risky change?
Straight-through rateWhat share completed the approved workflow without manual correction?
Exception-resolution timeHow long did valid exceptions remain unresolved?
Control override rateHow often did users bypass warnings or approvals?
Duplicate recovery/preventionHow many confirmed duplicate payments were prevented or recovered?
Post-payment defect rateHow many errors were found after cash was released?

The most important measures should be segmented by vendor, invoice format, language, legal entity, document quality, transaction type, and materiality. An impressive overall score can hide poor performance on rare suppliers or high-value exceptions. NIST's AI Risk Management Framework calls for documented human oversight, realistic evaluation, contextual interpretation of outputs, and ongoing attention to privacy, transparency, accountability, and reliability.

Confidence Is Not Authorization

A model's confidence score estimates something about the model's output under its design; it does not establish that the transaction is valid. A 99% confidence score on an extracted account number does not prove that the account belongs to the vendor. Likewise, a high-confidence coding suggestion does not prove compliance with company policy.

Design thresholds around the consequences of error:

High confidence + low-risk field

May flow automatically after validation.

Low confidence + critical field

Must stop for review.

Any vendor bank change

Must use independent verification regardless of confidence.

Any approval or segregation conflict

Must stop rather than auto-resolve.

Any material unusual transaction

Must escalate to an authorized reviewer.

Human Review That Works

Simply placing a person "in the loop" is not enough. Automation-bias research shows that users can over-rely on decision support, especially when verification is cognitively difficult. Reviewers need usable evidence and sufficient time—not merely an approval button.

A good review screen should show:

  • The original invoice next to extracted values.
  • Highlighted source regions for each extracted field.
  • Purchase order and receiving differences.
  • Prior invoices and payment history.
  • Vendor-master changes.
  • Rule results and model confidence by field.
  • Clear reasons for each alert.
  • A documented path to correct, reject, or escalate.

The reviewer should make an independent assessment before seeing a system recommendation when the risk of anchoring is high. Periodic "challenge sets" containing known errors can test whether reviewers still detect mistakes rather than mechanically approving the queue.

Control Blueprint

Governance

  • Inventory every model, rule, integration, service account, and vendor used in AP.
  • Assign an owner for model performance and an owner for the AP control process.
  • Define approved uses, prohibited uses, escalation rules, and change-management procedures.
  • Validate the system before production and after meaningful model, workflow, or data changes.
  • Contractually address data use, retention, access, incident notification, and subcontractors.

Data and access

  • Restrict AP, vendor-master, and bank-data access by role.
  • Require multifactor authentication for sensitive systems.
  • Encrypt sensitive data in transit and at rest according to organizational policy.
  • Prevent unapproved public AI tools from receiving invoices or vendor banking details.
  • Retain the original document, extracted values, corrections, approvals, and payment record.

Transaction controls

  • Validate totals, dates, tax fields, currencies, and vendor status.
  • Match PO invoices against purchasing and receiving records.
  • Search for exact and near-duplicate invoices.
  • Route exceptions rather than silently forcing records through.
  • Require independent approval for vendor creation and bank changes.
  • Separate invoice entry, vendor maintenance, approval, and payment release.
  • Reconcile payment files, bank activity, AP subledger, and general ledger.

Monitoring

  • Review extraction errors and overrides by user, vendor, and field.
  • Investigate sudden changes in straight-through processing.
  • Test false negatives with known duplicate and mismatch scenarios.
  • Review dormant, duplicate, and shared-bank-account vendors.
  • Monitor whether reviewers approve too quickly or ignore repeated alerts.
  • Suspend automation when performance exceeds defined risk tolerances.

What Should Never Be Fully Delegated

AI should not independently:

  • Create a vendor and release payment to that vendor.
  • Change vendor banking information and approve the change.
  • Decide whether unsupported goods or services were actually received.
  • Override a match exception without documented authority.
  • Determine the accounting treatment of a material novel transaction without review.
  • Replace approval evidence with a generated explanation.
  • Release cash solely because a model assigns a high confidence score.
  • Delete the original invoice or overwrite the history of corrections.

Practice: Release, Review, or Stop?

For each AP scenario, decide whether to Release, Review, or Stop, then reveal the best response.

Scenario 1

The invoice, purchase order, and receiving record agree. The vendor is established, no master data changed, mathematical checks pass, and the amount is within the normal approval path.

Scenario 2

The system reads an invoice total of $8,700 with 99% confidence, but the visible invoice total is $3,700.

Scenario 3

A long-standing vendor emails new routing instructions. The message comes from the normal email account and refers to a real unpaid invoice.

Scenario 4

Two invoices have the same vendor and amount. Their invoice numbers are 004817 and 4817, and their dates are three days apart.

Scenario 5

The invoice matches the purchase order, but there is no receiving record even though company policy requires one.

Scenario 6

AI suggests Office Supplies based on the vendor’s prior invoices, but the document describes a multi-year software implementation.

Score: 0/6 correct (0 reviewed)

Knowledge Check

Five questions on extraction vs. validation, three-way matching, duplicate detection, bank-change verification, and why an approval button alone is not enough.

Question 1: What is the difference between extraction and validation?

Question 2: What does a three-way match compare?

Question 3: Why can exact-match duplicate testing miss duplicates?

Question 4: Why should bank-account changes be verified outside email?

Question 5: Why is a human approval button not enough?

Key Takeaways

  • AI can accelerate AP by extracting invoice data, suggesting coding, matching records, and prioritizing exceptions—but it cannot prove a real obligation, authenticate a vendor bank account, or authorize cash on its own.
  • Treat “AI in AP” as a pipeline (intake through payment), not a single button: extraction, classification, matching, duplicate detection, fraud screening, posting, and payment each need different controls.
  • Product capabilities (for example, Microsoft invoice processing / Dynamics invoice capture) and org-specific accuracy figures (such as an 88% coding case study or a 76% touchless deployment) are not universal performance guarantees.
  • Preserve a bright line between preparing a transaction and authorizing cash: keep original evidence, validate critical fields, investigate exceptions, independently verify bank changes, segregate incompatible duties, and make automated decisions reconstructable.
  • Confidence is not authorization. High model confidence never replaces independent verification of vendor bank changes, match exceptions, or material unusual transactions.

The safest design preserves a bright line between preparing a transaction and authorizing cash. Keep original evidence, validate critical fields, investigate exceptions, independently verify vendor changes, segregate incompatible duties, measure real errors, and make every automated decision reconstructable after the fact.

Sources & Further Reading

Selected primary, research, and practice sources used in this module. Product docs describe capabilities, not guaranteed results. Accuracy figures remain tied to their study or deployment conditions. Recheck NIST, GAO, FBI, ACFE, and vendor sources when evaluating a control or tool.

Ready to Practice?

Take the release / review / stop habit from this lesson into the AI Practice Arena—judgment first, automation second.

Open AI Practice Arena

What's Next?

Next in the practice catalog is AI and the CPA Role (coming soon)—or return to the AI hub to revisit Foundations and related practice topics.

Related Concepts

Up Next

AI and the CPA Role