build.allanninal.dev

Part 5 of 7 · Document pipeline series ~4 min read

How the data flows out

Once a document is read and validated, the structured data goes wherever it’s actually useful — your sheet, your accounting software, a Slack channel. Each destination is a small pluggable piece.

The router: per-type fan-out to whichever tools you actually use A vertical flow with three branches at the bottom. At the top, “Approved fields” from the validator. An arrow leads down to a Router box that uses the rules file to decide where each document type belongs. From the Router, three labeled arrows fan out to three destination boxes: a Sheet on the left for receipts and similar light data, an Accounting tool in the middle for invoices, and a Notification channel (Slack or email) on the right for anything flagged or urgent. A bottom note reads: each destination is a small pluggable piece. Add new ones without touching the rest of the pipeline. Approved fields cleared by the validator Router rules say where each type belongs receipts invoices anything flagged Sheet a row per item, searchable Accounting QuickBooks, Xero, your books app Notification Slack or email, to a channel or person Each destination is a small pluggable piece. Add new ones without touching the rest of the pipeline.
Fig 5. The router fans out by document type. Each destination is its own small piece — pluggable, removable, replaceable.

Three common destinations

You don’t need to use all of these. Most clients pick one or two.

  • A sheet. One row per processed document. Easiest to start with, easiest to share with a non-technical colleague. Good for receipts, expense lists, simple form data.
  • Your accounting software. QuickBooks, Xero, or whatever already runs your books. The router talks to the software directly and writes the invoice or bill straight in — no manual re-entry.
  • A notification. A Slack message or an email when something needs eyes — a flagged extraction, a contract that just got signed, an invoice over a certain amount.

Per-type routing

The rules file from earlier doesn’t just describe what each document type looks like — it also says where each one should go.

For instance: receipts always go to the expense sheet. Invoices go to accounting and a Slack notification if the amount is above a threshold. Signed contracts go to a Drive folder and notify the legal contact. The router doesn’t make these decisions itself — it reads the rules and follows them.

This means you can change where things land by editing the rules file. No code change, no deploy.

Failures and retries

Destinations live outside your system. Sometimes they’re slow. Sometimes they’re down. Sometimes they reject your request because they decided to require a new field this morning.

The router treats each destination call independently:

  • If a call fails, it retries a few times with a small delay.
  • If it still fails, the message goes to a holding pen for failed sends — not lost.
  • The operator gets a single short notification: “3 documents couldn’t reach your accounting software.”

One destination going down doesn’t hold up the others. The sheet still updates even when accounting is offline.

Adding a new destination

A new destination is a small bit of code that takes a structured field set and pushes it somewhere — one function, maybe twenty lines. The rest of the pipeline doesn’t know or care that it exists.

So when a client says “can you also push these to our internal CRM?” the answer is yes, in an afternoon, without touching the reader, the validator, or any other destination.

In plain words

Structured data flows out the same way it came in — one piece at a time, where it’s actually needed. The router is the smallest, dumbest part of the pipeline; the smarts already happened. From here on, it’s plumbing.

All posts