Straight-Through Processing: When AI Handles Invoices End-to-End

What straight-through processing means for AP

Straight-through processing, or STP, is a concept borrowed from financial services where a transaction moves from initiation to settlement without manual intervention at any step. Applied to accounts payable, STP means an invoice arrives, gets extracted, validated, matched, approved, and queued for payment without a single person touching it.

This is not aspirational futurism. Large enterprises with mature AP automation platforms already achieve STP rates of 50-80% for routine invoices. The remaining 20-50% are exceptions that require human judgment -- missing PO references, price discrepancies, new vendors, or unusual amounts.

But achieving STP has traditionally required expensive enterprise software, months of implementation, and deep ERP integration. Mid-market companies have been priced out of this efficiency gain.

docrew changes the equation. By processing invoices locally with AI-based extraction, validation, and matching, organizations can build STP pipelines without enterprise software and without per-invoice transaction fees.

The conditions for touchless processing

Not every invoice can or should be processed without human review. STP works for invoices that meet specific conditions, and the system must be designed to identify which invoices qualify and which need human attention.

Known vendor. The invoice comes from a vendor already in the system with established payment terms, bank details, and approval thresholds. New vendors always require human review for initial setup and verification.

PO-backed purchase. A purchase order exists that the invoice can be matched against. The PO provides the pre-approved authority to spend -- the invoice is just confirmation that goods or services were delivered. Non-PO invoices (utilities, subscriptions, ad-hoc purchases) need a different approval path.

Within tolerance. The invoice amount matches the PO amount within a defined tolerance (typically 1-5%). Minor differences due to shipping, tax calculation, or rounding are accepted. Amounts that exceed the PO by more than the tolerance require human review.

Complete data. All required fields are present and valid: invoice number, date, vendor details, line items, totals, payment terms, banking information. Missing fields halt STP and route to exception handling.

No duplicates. The invoice number has not been seen before for this vendor. Duplicate detection prevents double payments.

Policy compliant. The invoice doesn't trigger policy rules requiring manual review: amount above approval threshold, vendor on watch list, unusual category.

When all conditions are met, the invoice moves through the entire pipeline without stopping. When any condition fails, the invoice exits the STP pipeline and enters an exception queue for human review.

The automated pipeline

STP for invoices consists of five sequential stages. Each stage either passes the invoice forward or routes it to exception handling.

Stage 1: Extraction

The invoice arrives as a PDF (or image, or email attachment). The AI reads the document and extracts all structured data: vendor name, vendor address, invoice number, invoice date, due date, PO reference, line items (description, quantity, unit price, amount), subtotal, tax, total, payment terms, and banking details.

Extraction must be highly accurate for STP to work. docrew reads the full document context, cross-references amounts (do line items sum to subtotal? does subtotal plus tax equal total?), and flags inconsistencies.

If extraction fails or produces low-confidence results, the invoice exits STP at this stage and goes to manual review with a note explaining what couldn't be extracted.

Stage 2: Validation

The extracted data is checked against business rules before any matching occurs.

Field completeness. Are all required fields populated? Missing invoice number, missing vendor details, or missing banking information halts STP.

Date logic. Is the invoice date reasonable (not in the future, not older than 90 days)? Is the due date after the invoice date? Do the payment terms align with the due date?

Amount checks. Are all amounts positive (except credit notes, which should be negative)? Do individual line item amounts equal quantity times unit price? Does the line item total equal the subtotal? Does subtotal plus tax equal the total?

Duplicate check. Has this vendor sent an invoice with this number before? Has an invoice with this exact amount from this vendor been processed in the last 90 days? Duplicate detection prevents the single most costly AP error.

Format validation. Is the bank account number in a valid format? Is the tax ID valid? Are currency codes recognized?

Validation catches extraction errors, data quality issues in the source invoice, and potential fraud indicators. Invoices that pass validation have clean, verified data ready for matching.

Stage 3: Matching

The validated invoice is matched against existing records: purchase orders, goods receipts, and contracts.

Two-way match (invoice to PO). The invoice PO reference is looked up. If found, line items are compared: quantities and prices checked within tolerance. If the match is clean, the invoice is confirmed as authorized spend.

Three-way match (invoice to PO to goods receipt). For physical goods, a goods receipt confirmation is also required. The match verifies that goods were ordered (PO), received (goods receipt), and billed (invoice) with consistent quantities and amounts.

Matching failures are the most common reason invoices exit STP. A missing PO reference, a quantity exceeding the ordered amount, or a price differing from the contracted rate -- all route to exception handling.

Stage 4: Approval routing

Invoices that pass matching are routed for approval based on organizational rules. In many STP implementations, this stage is automatic for invoices that match an existing PO because the PO itself represents pre-approval.

For non-PO invoices that have passed earlier stages (recurring charges with established vendor agreements, for example), approval may follow a rules-based path: invoices under $1,000 auto-approve, invoices between $1,000 and $10,000 route to the department manager, invoices over $10,000 route to the controller.

The key principle: if a human already approved the spend (by issuing a PO or signing a contract), the invoice does not need a second human approval as long as it matches the original authorization.

Stage 5: Payment queue

Approved invoices enter the payment queue with their extracted banking details, payment amount, due date, and any applicable discount for early payment. The treasury or AP team processes payments in batches -- typically weekly or bi-weekly -- using the queued data.

At this stage, the invoice has gone from a PDF arriving in an inbox to a validated, matched, approved payment instruction without anyone manually opening, reading, or entering the document.

The docrew workflow for STP

Building an STP pipeline with docrew starts with structured folders and clear instructions.

Folder structure. Create a processing folder with subfolders: incoming, extracted, validated, matched, approved, payment-queue, and exceptions. Each subfolder represents a pipeline stage.

Master data files. Place your vendor master list (vendor name, vendor ID, payment terms, bank details) and PO register (PO number, vendor, line items, amounts, status) as CSV files in a reference folder. These serve as the lookup tables for matching.

Pipeline instruction. Tell the agent: "Process each invoice in the incoming folder through these stages. First, extract all fields. Second, validate completeness, amounts, dates, and check for duplicates against the processed log. Third, match against POs in the PO register by PO reference. Fourth, auto-approve if PO-matched and within 3% tolerance. Move processed invoices through the stage folders. Move any invoice that fails a stage to the exceptions folder with a note explaining the failure reason. Append each processed invoice to the processing log."

Run the pipeline. The agent processes each invoice sequentially through all stages, moving files and building the processing log as it goes. Successful invoices end up in the payment-queue folder with a summary CSV ready for payment processing. Failed invoices end up in exceptions with detailed failure reasons.

Measuring STP rates

The STP rate is the percentage of invoices that pass through all stages without human intervention. Tracking this metric over time reveals both the effectiveness of your automation and the nature of your exceptions.

Calculation. STP rate = (invoices fully processed without human touch) / (total invoices received) x 100.

Typical starting point. When first implementing STP with docrew, expect an STP rate of 40-55%. The most common blockers are missing PO references, new vendors not in master data, and amount discrepancies beyond tolerance.

Target. After three to six months of refining rules and addressing systemic issues, a 65-80% STP rate is achievable for organizations with established purchasing processes.

Exception analysis. The exceptions tell you where to improve. If 30% of exceptions are "PO not found," the issue is vendor compliance with PO referencing, not the automation. If 20% are amount discrepancies, you may need to adjust tolerance thresholds.

Practical scenario: achieving 70% STP

A professional services company processes 400 vendor invoices per month. Their AP team of three spends most of their time on invoice processing: opening PDFs, entering data, matching to POs, getting approvals, and scheduling payments.

After implementing STP with docrew:

Month 1. STP rate: 45%. 180 invoices processed automatically, 220 routed to exceptions. Main reasons: 90 missing PO references, 40 from new vendors, 35 with amount discrepancies, 55 with other validation failures.

Month 3. After contacting vendors about PO references and expanding the vendor master: STP rate: 62%. 248 invoices processed automatically.

Month 6. After further refinements: STP rate: 72%. 288 invoices processed automatically. The AP team focuses on 112 exception invoices and process improvement rather than routine data entry.

The AP team's workload shifts fundamentally. Instead of processing 400 invoices manually, they review 112 exceptions and manage the pipeline. The freed capacity enables vendor negotiation, discount capture, and cash flow optimization.

Risk management and audit trails

Automating invoice processing raises legitimate concerns about control and oversight. If no human sees the invoice, how do you catch errors? How do you prevent fraud? How do you satisfy auditors?

Processing log. Every invoice that passes through the STP pipeline generates a detailed log entry: timestamp, extracted data, validation results (each check passed/failed), matching results (PO reference, match percentage, tolerance check), approval rule applied, and payment details. This log is the audit trail.

Exception transparency. Every invoice that exits the pipeline has a documented reason. Auditors can review not just what was processed, but what was rejected and why. This demonstrates that controls are active and functioning.

Threshold reviews. Even for STP-processed invoices, periodic sampling provides assurance. Review a random 5% of STP-processed invoices monthly to verify that extraction, matching, and approval were correct.

Separation of duties. STP doesn't eliminate segregation. The person who sets up vendor master data (including bank details) should be different from the person who processes payments. The automated pipeline sits between these roles, not replacing them.

docrew processes all of this locally. The invoice data, vendor master, PO register, and processing logs all reside on your computer. No third party has access to your vendor relationships, pricing, payment terms, or cash flow patterns. For organizations where AP data confidentiality matters -- and it should matter everywhere -- this local processing model eliminates an entire category of data exposure risk.

When STP is and isn't appropriate

STP is most effective for routine, repetitive, high-volume invoices from established vendors with clear PO backing. It is least effective for complex, one-off, or relationship-sensitive transactions.

Good STP candidates. Regular supply chain invoices, recurring service charges, utility bills, standard maintenance contracts, subscription renewals.

Poor STP candidates. First invoices from new vendors (need human onboarding), invoices for capital expenditures (need budget approval), invoices related to disputes or claims (need judgment), invoices from related parties (need compliance review).

The goal is not 100% STP. The goal is to automate the routine so that your AP team's expertise is applied where it matters: the complex, ambiguous, and high-risk transactions that genuinely require human judgment. docrew handles the predictable so your team can focus on the exceptions.