Building an Invoice Automation Pipeline: OCR, Webhooks, and Approval Logic

A finance team’s request usually sounds simple: cut down on manual invoice entry. In practice, that request splits into five separate engineering problems: getting invoices into one place, turning documents into structured data, matching that data against a purchase order, routing it through approval, and catching anything that stalls.

None of these problems is hard by itself. Stitching all five together correctly is where most in-house builds fall apart.

The instinct is usually to build this inside the ERP, since that’s where the invoice eventually has to land anyway. It rarely works out.

ERPs are built to record a transaction accurately, not to referee a stream of unstructured documents arriving in five different formats, and that gap is well documented in why ERP workflows struggle with modern AP complexity.

The practical fix is to build the pipeline as a separate service and sync clean, approved data into the ERP at the end, instead of trying to force the whole process inside it.

The Pipeline, End to End

An invoice automation pipeline breaks into five stages, and each one is its own engineering problem with its own failure mode.

Designing a Single Intake Point

Every intake channel you add is another code path that can break silently.

Vendors will email PDFs, upload to a portal, and occasionally still mail paper. Rather than writing separate handling for each source, normalize everything into one internal event shape the moment it arrives, before any other part of the pipeline touches it.

An inbound-email service like Mailgun Routes or Postmark’s inbound webhooks can turn an email and its attachment into a webhook call automatically. A portal upload can post to that same internal endpoint. Downstream code only ever needs to know about one shape:

{
  "invoice_id": "inv_8841",
  "source": "email",
  "vendor_email": "[email protected]",
  "received_at": "2026-07-30T09:12:00Z",
  "attachment_url": "https://storage.example.com/invoices/inv_8841.pdf"
}

Everything after this point, extraction, validation, routing, is written against that one schema, regardless of where the invoice actually came from.

Treat that intake endpoint as a trust boundary, not just a data format. Anyone who finds the URL can, in principle, POST a fake invoice at it.

Verify the signature your inbound-email provider attaches to each request (Mailgun and Postmark both sign their webhook payloads) and reject anything that doesn’t check out before it touches the rest of the pipeline.

A portal upload needs the same discipline: require an authenticated vendor session rather than an open upload form. Intake is the easiest point in the whole system to attack, precisely because it’s built to accept things from outside.

Turning Documents into Structured Data

OCR is the step where a PDF stops being a picture and starts being data you can route.

An invoice OCR API reads the attached PDF or image and returns vendor name, line items, amounts, tax, and currency as structured JSON, usually within a couple of seconds.

Accuracy depends heavily on scan quality and how well the model has been trained on your specific vendor formats, so budget for a manual-review queue early on, not as an afterthought. A typical extraction response looks something like this:

{
  "vendor_name": "Acme Supplies Co.",
  "invoice_number": "AC-2291",
  "currency": "USD",
  "total_amount": 4230.50,
  "line_items": [
    { "description": "Packaging materials", "quantity": 500, "unit_price": 3.40 }
  ]
}

That response usually needs some picking apart before it’s actually usable. If you’re debugging why a field extracted wrong, a JSON formatter turns the raw payload into something readable in seconds instead of a wall of brackets.

If you only need a handful of fields out of a much larger nested response, say pulling line_items[2].unit_price without writing a one-off parser, a JSON extractor with dot-notation path support handles that directly.

Some extractions include a vendor’s bank account details for direct deposit. Store those fields separately from the rest of the invoice record, encrypted at rest, with access limited to whatever process actually issues payment. They don’t belong in the same table your approval dashboard queries every time someone checks a status.

Approval Logic Belongs in Config, Not Code

Hardcoded approval logic is the first thing that breaks the moment finance changes a policy.

Model each rule as data instead of an if-statement buried in your application:

{
  "rule": "amount_threshold",
  "condition": "total_amount > 5000",
  "action": "route_to",
  "approver_role": "finance_director"
}

A small rules engine reads this config and routes accordingly, which means finance can adjust a threshold without filing an engineering ticket. Two checks belong in validation before that rule engine ever sees the invoice, though.

First, normalize the amount to a base currency before comparing it against a threshold. A rule written as total_amount > 5000 is only correct if every incoming invoice is already in the same currency, which stops being true the moment you take on an international vendor. Convert first, evaluate second, or the threshold silently means different things depending on where the invoice came from.

Second, check for duplicates and vendor changes before routing anything. Match on vendor ID plus invoice number, and hold anything that already exists in the system, whether it’s an honest resubmission or the start of billing fraud.

Treat a vendor’s bank details changing between invoices the same way: flag it for a human to confirm by phone before the payment goes out, not by replying to the email that requested the change. Business email compromise scams specifically target this step, and OCR extracting a new account number cleanly doesn’t mean it’s legitimate.

Once those two checks pass, flag anything that doesn’t match the PO as an exception for a human to review. Don’t auto-approve on a partial match, and don’t silently overwrite the PO’s correct value with whatever the OCR step happened to extract.

Escalation Needs to Be Idempotent, Not Just Automatic

An escalation job that fires twice is worse than one that doesn’t fire at all.

A scheduled job checks pending approvals against elapsed time: a reminder at two days, an escalation to the approver’s manager at three, a notification to the finance director at five. Whether that job runs on a cron entry or a managed scheduler, get the timing right the first time.

A tool like CodeItBro’s crontab generator turns “every day at 9 AM” into the exact five-field expression your scheduler expects, which matters more than it sounds like once a mistyped field means the check silently stops running at 9 PM instead. The core logic itself is straightforward:

for invoice in pending_approvals():
    days_pending = now() - invoice.submitted_at
    if days_pending >= 5 and not invoice.escalated_to_director:
        notify(finance_director, invoice)
        invoice.escalated_to_director = True
    elif days_pending >= 3 and not invoice.escalated_to_manager:
        notify(invoice.approver.manager, invoice)
        invoice.escalated_to_manager = True

The part teams miss is that scheduled jobs and webhook deliveries both retry on failure, which means this code can run more than once for the same invoice. Without a guard, a worker restart turns into five duplicate Slack pings to your finance director.

Stripe’s own guidance on idempotent requests covers the same underlying problem for payment events, and the fix is the same pattern here: store an “already escalated at this threshold” flag per invoice, and check it before firing a notification, not after.

If you’d rather not hand-roll the scheduler, this is the same event-driven pattern behind webhook-triggered workflows in n8n: a trigger checks elapsed time, a webhook call handles the notification, and the platform’s own retry logic replaces the custom queue code above.

Syncing Approved Invoices Back to the ERP

The ERP should be the last stop in this pipeline, not the workspace.

Once an invoice clears approval, push the clean, structured record into the ERP through its API. Plenty of ERP integrations are batch or nightly rather than real-time, so build this as a queue with retry logic instead of assuming a synchronous write always succeeds.

If a sync fails, the invoice should stay marked as “approved, not yet posted” rather than silently disappearing from the pipeline’s view.

Monitoring: Make the Pipeline Observable

A pipeline nobody can inspect turns into another black box finance has to trust blindly.

Expose a status endpoint or dashboard that shows every invoice’s current stage, timestamps for each transition, and any failures along the way.

Log OCR confidence scores below your review threshold so low-confidence extractions get eyes on them before they cause a downstream mismatch.

Alert on a stuck queue, not just a stuck invoice. One invoice sitting for a week is a process problem. A hundred invoices stuck at the same stage is an outage.

Frequently Asked Questions (FAQs)

What OCR accuracy should I expect out of the box?

It varies by vendor and document quality. Clean, standard invoice formats from established vendors tend to extract close to perfectly. Handwritten notes, poor scans, and unusual layouts need manual review, especially in the first few weeks while the model builds up experience with your specific vendor base.

How do I keep escalation jobs from double-firing?

Store a flag per invoice per escalation threshold, and check it before sending a notification rather than after. Treat the notification step the same way you’d treat any other side effect triggered by a retryable job: idempotent by design, not by luck.

How do I catch duplicate or fraudulent invoices?

Match every new invoice against vendor ID plus invoice number before it enters the approval flow, and hold anything that already exists for review instead of processing it again. Treat any change to a vendor’s bank details as its own event: confirm it by phone through a number you already have on file, not by replying to the email that requested the change. That single check stops most business email compromise attempts targeting AP.

Should approval rules live in code or a config file?

Config, wherever possible. Thresholds and routing rules change on finance’s schedule, not your deploy schedule. Keeping them in a config file or a small rules table means someone in finance can adjust a number without waiting on engineering.

How do I test this pipeline without real vendor invoices?

Build a small set of fixture PDFs and JSON payloads that mimic real OCR output, including a few deliberately malformed ones. Run the validation and escalation logic against those fixtures in CI, and save real invoice testing for a staging environment with a handful of actual (non-sensitive) vendor documents.