Invoices arrive as PDFs and leave as typing

The situation

Invoices arrive by email as PDFs and scans, in every supplier’s own layout. Someone reads them and types the header and the lines into a finance system, checks them against the purchase order by eye, and routes them for approval. Duplicates slip through because a duplicate is only obvious if you are looking at both at once.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the invoice, including its lines

   An invoice is a header and a variable number of lines, so lines repeat. Invoice number is marked unique per supplier and the amounts are typed, so the model rejects what a spreadsheet would have accepted.

   What it uses: Repeating sections, with per-field rules including unique and typed values

2. 2

   Read the document instead of retyping it

   Upload the PDF or photograph and have its values extracted against the published invoice schema. The extraction is a draft: it is reviewed, regenerated or discarded before anything is created, so a bad read is caught by a person rather than paid.

   What it uses: Values extracted from a completed document against a published schema

3. 3

   Keep the original attached

   The source document uploads straight to storage through a short-lived signed link and attaches to the record, with signed links for download and PDF viewing. Large files never travel through the application, and the evidence stays with the record it produced.

   What it uses: Direct-to-storage upload with short-lived signed links

4. 4

   Define what a duplicate actually is

   Duplicate rules are defined on the schema — supplier and invoice number exactly, with a similarity threshold for the near misses that differ by a space or a leading zero. Those rules are stored with the schema version, so they are versioned alongside it rather than living in whichever import script ran.

   What it uses: Duplicate detection defined on the schema, with a similarity threshold

5. 5

   Match it against the order before anyone approves

   A step reads the purchase order record mid-run and compares totals and lines against it. The invoice may have arrived days earlier; the comparison uses the order as it stands today. A mismatch leaves by a different link, and anything the conditions do not cover falls through to the link marked as the default.

   What it uses: A step that reads the record mid-run, and conditional links

6. 6

   Route the exceptions to a person

   A mismatch becomes a human decision step with your own reason codes, so why an invoice was held is reportable data. A sentence typed into a comment box is not. The task keeps the options and the form it was created with, so editing the workflow leaves open tasks alone.

   What it uses: Human decision steps with reason codes, fixed at task creation

7. 7

   Post it, and tell the systems that care

   The approved invoice posts to the finance system as a mapped step. Downstream systems subscribe to the record events instead of polling for them: deliveries are signed, they retry on failure, and every attempt is in the log.

   What it uses: Mapped step inputs, and signed event delivery with retries

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.