How a document becomes a record

A supplier emails an invoice. Somewhere after that there is a bill in QuickBooks, coded to the right vendor, waiting for someone to pay it. In most finance teams the middle of that sentence is a person with two windows open.

This post walks the middle.

Where the document comes in#

Work enters a workspace through surfaces, and every plan carries all three, Solo included.

• Upload. Drop the file into the workspace.
• The workspace inbox. Every workspace has its own email address. Forward the invoice, or ask the supplier to send it straight there, and the run starts without anyone opening Braille.
• A webhook endpoint. Post the file from a system you already run.

A workflow can also start from an app trigger, such as a new file landing in a Google Drive folder. Whichever surface a document arrives on, it joins the same queue and runs against the same schema. You can start on uploads while a workflow is young, move it to the inbox once you trust it, and nothing about the run itself changes.

The schema is the question you are asking#

A workspace holds the documents, the schema and the connected apps for one kind of work: bills for one entity, applicant packs for one role, enquiry forms for one team.

The schema is the list of fields you want out of every document in that workspace. For a supplier invoice that is usually the vendor, the invoice number, the issue date, the due date, the subtotal, the tax and the total. You write it once and every run answers it.

Reading a document against a schema is what makes the output checkable. A filled schema is a row your team can scan and approve. It is also the thing that can be written into another system without a human in the middle.

Reading#

Braille reads PDFs, images and spreadsheets, whatever the layout. Suppliers do not agree on where the total goes, or what to call it, or whether the tax is a line or a footer, so Braille finds the fields you asked for wherever they sit. The values land in the schema, ready to check before anyone opens the file.

Matching#

The vendor name on the invoice is a piece of text. The vendor in QuickBooks is a record with an ID, payment terms, a default expense account and a history of everything you have already paid it.

Braille looks the extracted vendor up in the connected app and writes that app's real ID into the schema. When the vendor already exists, no second one is created.

This is the step that turns a filled form into a record, and it is worth its own post: what matching actually does.

The write#

A workflow produces one output, the single business outcome it exists to land. For this run that is a bill in QuickBooks, against the matched vendor, carrying the values from the invoice.

The writes needed to make that output possible are supporting actions, and they cost nothing. If the vendor genuinely does not exist yet and has to be created so the bill can exist, that creation belongs to this run and is free.

Where the approval step sits#

An approval step can sit in front of any write. When it does, the record waits with every field visible, beside the document the values came from, until someone signs off. Nothing reaches QuickBooks until they do.

Who signs off is a workspace question. The Business plan carries approver and uploader roles and workspace routing, so the person who forwards a document is not automatically the person who releases it.

The useful pattern is to put an approval in front while a workflow is young, then keep it only where you want it: over a value you set, on a new supplier, on a document type that still surprises you.

What is left behind#

Every run records what was written, where it was written and by whom, and keeps the document beside it. When somebody asks in March why a bill is coded the way it is, the run is the answer.

Watch one#

The interactive demo runs a sample document through these steps, one step at a time, and shows the schema and the written record as they fill. The steps are scripted with sample data, in the same order a real run takes them.