Flowgrammer

Accounts Payable Automation

Controlled AP from intake through a reviewed draft bill, with matching, approvals, exceptions, and an explicit payment boundary.

— Craig Major

What accounts payable automation is

Accounts payable automation is a controlled path from supplier invoice intake through validation, matching or coding, approval, a draft accounting write, and reconciliation. A person still approves every non-duplicate before any draft bill exists. Payment execution, remittance, and supplier bank-detail changes stay outside this first system.

For extraction, field checks, and the five fictional intake-to-draft cases, start with invoice processing automation.

Who this is for

Use this when invoices already have a named intake path and you can say what object your accounting system creates for a supplier bill. In many products that object is a bill or pending vendor invoice, not a sales invoice.

Prerequisites:

  • One primary accounting or AP destination for the first build
  • Named approvers and an exception owner
  • A written rule for PO versus non-PO invoices
  • A duplicate key you can test
  • Fictional or approved samples before any live write

Leave these out of the first system: autonomous payment, remittance files, supplier bank-detail changes, tax advice, multi-entity ERP rollout, and any claim that a model confidence score is posting authority.

If you still need to decide what to automate first, use Document Processing Automation.

When a tracker stops being enough

An invoice tracker is a status register. Keep it while one team, one intake path, and one destination are enough. Move on when more than one mailbox or folder creates duplicate rows, reviewers need routing or an audit trail a shared sheet cannot protect, approved rows must create a draft in accounting without retyping, exception volume forces a queue-only work style, or you need extraction, confidence checks, and retries.

Accounts payable automation is what you design after that handoff. It does not make the tracker wrong. It adds matching, authority, segregation of duties, a draft-only destination contract, and an explicit payment boundary.

If the pain is still "we cannot read the PDF," start with intelligent document processing. Capture is not AP.

Worked example

Cedar & Quay Fabrication Ltd is a fictional Toronto buyer. Ridgemont Industrial Supply Co sends invoice INV-TP-2401 dated 8 September 2026. Safety vests, clipboards, and fastener bins. Subtotal CAD 400.00, HST CAD 52.00, total CAD 452.00. Purchase order PO-CQ-188 is on the page. The HST 13% label is fixture vocabulary, not tax advice.

The AP system should:

  1. Store the original and a SHA-256 of the bytes.
  2. Validate vendor, invoice number, date, currency, lines, and totals against the invoice-output schema from invoice processing.
  3. Stop if the same hash or the same vendor plus invoice number was already seen.
  4. If policy says PO invoices need two-way matching, compare price and amount to PO-CQ-188 within a buyer-set tolerance.
  5. Suggest an expense account and a tax-code label. Stop if either is ambiguous.
  6. Wait for an explicit approve. Then create one draft bill. Do not create a payment.

That clean case is fixture 01-clean-invoice.txt from the Invoice Processing Test Pack. The four failure fixtures reuse the same companies. They are fictional. They do not measure OCR.

The AP workflow

  1. Intake. Receive the file from the agreed mailbox, folder, portal, scan drop, or structured feed. Register channel, owner, and original. Do not edit vendor master data from the attachment.
  2. Validate. Map into the invoice-output schema. Require vendor, invoice number, date, currency, and total. Check line math and that subtotal plus tax matches the printed total within ordinary rounding.
  3. Match or code. If a purchase order is required, resolve it. Two-way matching compares the invoice to the PO. Three-way matching also compares quantity to a product receipt. Microsoft's Dynamics 365 Finance docs use that vocabulary. Three-way matching is optional scope, not a default. Non-PO invoices take a coding path instead.
  4. Approve. Route by amount, department, or exception code. Record who approved. A missing reviewer means the status stays pending and the destination is not called.
  5. Draft-post. After approve, write one draft bill, vendor bill, or pending vendor invoice. Attach the source if the destination allows it. Store the destination id against the intake record.
  6. Reconcile. Review unpaid drafts against A/P aging and later bank activity. Reconciliation is a control. It is not a licence to auto-pay.

Invoice processing is steps 1, 2, and 5 with a human gate. AP automation is the same spine plus match/code, RACI, exceptions, and reconcile, still without payment.

Matching and coding

Document class Automatic support Person required
Non-PO utility or service invoice Suggest a default account and tax-code label Confirm coding when the map is empty or mixed
PO present, two-way policy Compare unit price or net amount to the PO Accept or reject a variance beyond tolerance
PO present, three-way policy Compare invoice quantity to a receipt Hold for receiving or an elevated approve
PO required but missing Flag PO_REQUIRED_MISSING Procurement or AP lead decides
Tax label does not map to a company tax code Stop A person chooses the code. No GST, HST, or QST treatment is prescribed here

Xero, QuickBooks, and other mid-market tools do not all natively run three-way matching. Confirm the destination you will actually use. Microsoft Learn documents two-way and three-way policies for Dynamics 365 Finance. That is vocabulary and a scope flag, not a requirement for every SMB.

GST/HST/QST names and CRA documentary bands belong on a field inventory. They are not an input-tax-credit decision engine. Re-open the current CRA pages before you quote a rate. The fixture uses HST 13% because the fictional buyer is in Ontario on the test date.

What can run automatically, and what cannot

Situation Automatic action Person required
File stored and hashed Yes No
Fields mapped into the invoice schema Yes No, unless capture fails
Required fields present and totals add up Flag ready for review or matching Yes before any draft write
Same bytes or same vendor plus invoice number Status duplicate. No review. No destination. Only a later documented override. The test pack default is deny.
Two-way or three-way variance beyond tolerance Flag a match exception Yes
Ambiguous vendor or tax code Stop Yes. Do not auto-create a vendor.
Reviewer chooses approve Create one draft The approve decision itself
Destination writes, then the response is lost Retry the same idempotency key Confirm the existing draft id
Payment, remittance, or supplier bank-detail change Never in this system Entirely outside

COSO describes authorizations, verifications, reconciliations, and typically segregation of duties as control activities. ISACA's SoD writing says no person should be able to commit and conceal an error in the normal course of their duties. Use that as vocabulary, not as a certification, audit opinion, or fraud guarantee.

Incompatible pairs to write down even in a small team:

  • Vendor master maintenance, especially bank details, versus payment release
  • Invoice entry or coding versus sole approval of the same invoice
  • Approval versus payment release
  • Payment release versus bank reconciliation

If the same owner must wear two of those hats, record a compensating review. That is a prompt, not a promise that fraud cannot happen.

Human gates

A person keeps these decisions:

  • Approve or reject every non-duplicate before a draft write
  • Vendor ambiguity and any new-vendor request
  • Missing invoice number or conflicting total
  • Match variances beyond the buyer tolerance
  • Tax-code or account-coding ambiguity
  • Every supplier bank-detail change, verified out of band
  • Payment release

A confidence score can send a document to review. It cannot approve a draft. It cannot pay a vendor.

Failure paths

Failure Expected status Destination Payment
Duplicate source hash or vendor plus invoice number duplicate Zero writes Blocked
Missing invoice number human_stop / MISSING_INVOICE_NO No write unless a later override exists Blocked
Printed total does not match subtotal plus tax human_stop / CONFLICTING_TOTAL No write unless a later override exists Blocked
Vendor 0 or many matches human_stop / VENDOR_AMBIGUOUS No write Blocked
Bank-detail change requested from the invoice or email human_stop_out_of_band Not a draft-write path Blocked
Approval missing or expired pending_review Zero attempts Blocked
Destination timeout after a write Retry same application key Write count stays 1 Blocked
Any attempt to create a payment entity UNAUTHORIZED_PAYMENT_ATTEMPT Forbidden Forbidden

Microsoft's vendor-invoice reference architecture uses invoice number plus vendor identifier so a redelivered email does not create a second ERP record. Use the pattern. Leave that page's stated service-level target and any vendor case-study percentage out of your design.

Intuit documents a Bill as the pay-later AP object and BillPayment as the object that pays bills. NetSuite documents entering a vendor bill as recording a payable, with payment as a later payables action. Those cites lock the draft-only contract. They are not a QuickBooks or NetSuite implementation walkthrough.

Test cases

The five labeled-text fixtures from the Invoice Processing Test Pack are the test set. They prove workflow gates, not scan OCR.

Case Fixture Without reviewer After the AP control
Clean 01-clean-invoice.txt pending_review, 0 writes Approve → one draft bill. Optional two-way if PO-CQ-188 is in policy. Payment entities = 0
Duplicate 02-duplicate-invoice.txt duplicate No review. No draft. Payment entities = 0
Missing number 03-missing-invoice-number.txt human_stop Exception MISSING_INVOICE_NO. No draft
Conflicting total 04-conflicting-total.txt human_stop Exception CONFLICTING_TOTAL. No draft
Destination timeout 05-ambiguous-destination-timeout.txt pending_review, 0 writes Approve → two destination attempts, one stored write, same draft id. Still no payment

The AP Readiness Checklist and Exception Matrix adds PO/non-PO flags, RACI, exception codes, and the payment-blocked column on top of those fixtures.

What to measure

Record invoices received by channel, exception counts by code, duplicate stops, match variances, queue age, approvals, destination attempts, destination writes, and unpaid draft aging. Put your numbers in the readiness pack. Keep them as operational counts, not as a savings, cycle-time, error-rate, or fraud-percentage result.

The Automation ROI Calculator is a planning worksheet. Replace its illustration with observed AP counts. Staff minutes released are not automatically cash saved.

There is no live production AP metric here, and no Flowgrammer customer AP case.

How to use the readiness pack

The paired asset is a readiness and control workbook, not another invoice tracker starter.

  1. Open the Cover sheet and read the payment boundary.
  2. Inventory intake channels and write your own volumes. Leave benchmark cells blank until you have counts.
  3. Confirm document fields against the invoice-output schema and the CRA documentary vocabulary list. That list is not tax advice.
  4. Write matching policy: PO versus non-PO, two-way, and whether three-way is in scope.
  5. Fill ApprovalRACI and the incompatible-duty pairs.
  6. Walk the five fictional cases and record expected draft writes and payment entity counts.
  7. Use VendorQuestions as category questions, not as a BILL versus Ramp scorecard.

Realistic limitations

  • Extraction does not prove goods were received or that a supplier is genuine.
  • Labeled-text fixtures do not measure OCR accuracy.
  • Three-way matching, multiple legal entities, and ERP depth can change the build. They are not hidden in a cheap default.
  • Accounting objects differ by product. Read the current Bill, vendor bill, or pending vendor invoice docs for the destination you will use.
  • This system does not pay anyone and does not change supplier bank details.
  • CRA, COSO, and ISACA cites are vocabulary. They are not advice, certification, or an audit opinion.
  • This guide does not rank vendors, and it is not a QuickBooks, payment-platform, or ERP product walkthrough.

FAQ

What is accounts payable automation?

It is the controlled path from supplier invoice intake through validation, matching or coding, approval, a draft accounting write, and reconciliation. Payment stays outside the first system.

How is this different from invoice processing automation?

Invoice processing moves one invoice family from intake to a reviewed draft. Accounts payable automation adds matching or coding policy, approval authority, exception ownership, reconciliation, and an explicit payment boundary on top of that draft.

When is an accounts payable tracker not enough?

When invoices arrive through more than one channel, reviewers need a protected audit trail, approved rows must create a draft without retyping, exceptions need a queue, or you need extraction and retries. Those signals are already on the invoice tracker.

Does accounts payable automation pay vendors?

No. Automation may create a reviewed draft bill. Payment execution, remittance, and supplier bank-detail changes remain outside this guide.

Do the five test cases measure OCR?

No. They are labeled-text fixtures from the Invoice Processing Test Pack. They prove control outcomes. They do not prove PDF or scan extraction.

What is two-way versus three-way matching?

Two-way matching compares the invoice to the purchase order. Three-way matching also compares quantity to a product receipt. Microsoft documents that distinction for Dynamics 365 Finance. Three-way matching is optional scope here.

Next step

Download the AP Readiness Checklist and Exception Matrix and fill it with your channels, approvers, and exception codes.

If intake, matching policy, approvers, or the draft object are still unclear, start with an AI Success Audit. If those pieces are already named, book a fit call to scope an AI Automation Systems build.

Sources