How purchase order
automation actually works.

1. What does intake accept today?

An uploaded document: PDF, PNG or JPEG. A text-bearing PDF is read page by page into stored text artifacts. A scan or photograph goes through optical recognition first. Both end up as immutable artifacts that later stages cite, which means the words a reviewer sees are always traceable back to bytes that were actually received. Reading orders directly from a mailbox is planned but not built yet — email intake stays labelled roadmap until it genuinely exists.

2. Is this OCR, or AI document extraction?

Both, in different jobs. Recognition turns pixels into candidate text; extraction decides which parts of that text are order facts and which line each fact belongs to. The pipeline prefers deterministic reading wherever page structure already answers the question, and spends model effort where layout is messy, labels differ between customers, or a table’s columns do not line up cleanly. That keeps cost down and makes behaviour predictable instead of mysterious.

3. How do I verify what it claims to have read?

Each accepted value is shown beside its source highlight: the page number plus character offsets into that page’s text artifact. Reviewing an amount becomes “open page 2, look at this span” rather than re-reading the whole PO hunting for a discrepancy. Facts with no defensible source stay empty and carry an issue code. Printed values on the customer’s document and values derived by arithmetic are kept separately, so a mismatch between your total and their printed total surfaces as a finding instead of being quietly smoothed over.

4. What happens when the file has no readable text layer?

The run stops and parks. A blurred scan, a cropped footer or recognition too unreliable to defend does not get filled in with plausible guesses; blocking issues explain which facts could not be established. Some teams dislike that because they would prefer momentum. The alternative — inventing quantities, SKUs or prices that then travel into picking and invoicing — costs considerably more than one extra look at a bad scan.

5. How does catalogue matching decide a line?

In order of trustworthiness: an exact SKU you publish, then an alias scoped to that specific customer (customers routinely use their own item codes), then a normalised identifier comparison. When two products remain equally plausible, both candidates are listed with alternatives and the method used is reported — the choice stays human. Quantity gets converted only through a conversion rule published in your catalogue, never inferred from how a description reads.

6. What if nothing matches?

The line carries an explicit unmatched flag and comes to review with its extracted wording preserved as written. Unmatched lines are ordinary events, not edge cases: customers add items, discontinue codes and typo part numbers constantly. Reporting them plainly keeps a small correction visible while it is still cheap to fix. See who this suits for the industries where unmatched lines appear most often.

Validation before anyone sees it

Deterministic checks run against the draft built from that document: required fields present, quantities carrying units, arithmetic consistent within each line and in totals, catalogue references resolvable, currency valid. Findings get typed codes, and some of them block approval by default rather than merely warning.

Why blocking issues cannot be dismissed

The review screen offers corrections, not overrides. A patch must name a field it is permitted to correct, hold a value valid for that field, and cite text produced from this very document. Attempts to edit verdicts directly — clearing a blocker flag, rewriting findings, adjusting computed totals — are refused. The issue disappears because validation no longer reports it, not because someone said to ignore it.

What an approval actually commits

Approval binds to one exact revision plus its content hash, recorded for an authorised reviewer with no unresolved blockers. Approving does not export. Exporting is a separate deliberate action on that approved revision only, producing CSV or JSON. Save a correction later and you create a new revision; any live approval attached to the older one stops standing. It feels rigid until somebody edits a signed-off order and nobody can prove which version went out.

Who sees what across a team

Roles are separated: uploading documents, reviewing and correcting them, administering catalogue and policy. Data belongs to one tenant and separation is enforced in the database rather than by trusting application code alone. Catalogue versions and policy versions are immutable snapshots pinned per run, so a decision made last month can be replayed against exactly the rules that applied then, with an audit trail naming who changed what and why.