Skip to main content
Most workflows only use the first two steps — Parse and Extract. The rest are there for when your documents are more complicated, or when you want something back other than data.

​
Parse

Parse step Reads the document. Parse turns your file (PDFs, images, CSVs, and more) into clean text and tables that the rest of the workflow can work with. Every workflow starts with a Parse step.
  • You configure: usually nothing — Parse works out of the box. Advanced options let you give a hint about the document or tune how figures are handled.
  • Add it when: always. It’s the first step in every workflow.
Example: upload a bank statement PDF — Parse reads and prepares all the text and layout.
Configuring the Parse step

​
Extract

Extract step Pulls out the fields you ask for. Extract takes the text from Parse and returns structured data according to the fields you define.
  • You configure: the list of fields — each with a name, a type, and an instruction. This is your schema. A field can also be resolved from an uploaded reference file instead of the document — see Smart Lookup.
  • Add it when: you want specific values back (the usual case). Skip it only for a parse-only workflow.
Example: define fields like “Account number”, “Transaction date”, and “Amount” to get them from every statement.
Configuring the Extract step

​
Classify

Classify step Sorts documents into types you define. Classify looks at each document and labels it as one of the categories you set up, so you can handle each type differently downstream.
  • You configure: a list of categories, each with a name and a short description of what belongs in it.
  • Add it when: one workflow needs to handle several kinds of document — for example a mailbox that receives both invoices and contracts. After Classify, connect a separate Extract step for each category.
Example: automatically label incoming files as “Invoice”, “Contract”, or “Statement”.
Configuring the Classify step

​
Split

Split step Breaks one file into several documents. Split takes a single file that actually contains multiple documents and separates it into pieces, so each piece is processed on its own.
  • You configure: the split rules, each with a name and a description. Anything that doesn’t match a rule is grouped as “other”.
  • Add it when: your uploads bundle several documents together — for example a single PDF with four invoices, or a 50-page report you want handled page by page.
Example: a 50-page report gets split so each section is processed separately.
Configuring the Split step

​
Validate (Beta)

Validate step Checks the results against rules you write. Validate takes the data from an Extract step and tests it against rules you describe in plain language, then flags anything that fails — so problems surface automatically instead of slipping through.
Validate vs. verify — two different things. The Validate step is an automatic check built into the workflow: anyformat runs your rules on every document. Verifying is something you do by hand afterward — marking a value as correct with the thumbs-up (see Verification & review). One is the machine checking your rules; the other is you confirming the result.
  • You configure: a list of rules. Each rule is one of two kinds — an AI rule you describe in plain language (for example, “the IBAN is a valid format” or “the document is not expired”), or a deterministic rule you build from a structured check (a number/date in range, a + b = c, a value in a set, a pattern match, a required field) that runs instantly with no AI. You can mix both in the same step.
  • Add it when: some results must meet conditions, and you want failures flagged automatically. Place Validate after the Extract step whose output you want to check.
  • Where results show up: failures appear in the Validation tab of the results, alongside the extracted data.
Example: check that the name on an ID matches the name on the contract (AI), confirm the invoice year is between 1995 and 2050, or that subtotal + tax equals the total (deterministic).
See Validation rules for the full list of deterministic checks and when to choose AI vs deterministic. Configuring the Validate step

​
Edit (Alpha)

Fills in a blank form and hands back the completed PDF. Edit reads the fillable gaps off the document Parse produced — you don’t map fields by hand — and writes your values into them, returning a filled PDF you can download.
  • You configure: the values to fill in, either as free text (Name: ACME SL; Date: 2026-01-01) or as a reference document you upload once, or both. A reference is your standing data — a company profile CSV, an employee handbook PDF — and every run fills from it without you retyping anything. Where both address the same field, your free-text instructions win.
  • You also choose: the typeface, and whether the output is flattened (final, values painted on) or editable (each value stays in a live form field a reviewer can correct in any PDF viewer).
  • Add it when: you need a filled document back, not data out. Place Edit directly after Parse.
Example: drop in a blank supplier onboarding form and get it back completed from your company profile.
A reference document is parsed once, when you upload it — never on every run. PDF references are billed a flat charge at that point; text references (.csv, .txt, .md, .rst) are free. If a reference hasn’t finished processing, the run is refused rather than filled from a partial reference.
Through the API, upload references to the workflow and put the returned ids on the node:
A .csv comes back ready immediately. A .pdf comes back pending while it is parsed — poll GET /v3/workflows/{workflow_id}/edit-references/ until it settles, then set reference_document_ids: ["069dcc2c-…"] on the Edit node.

​
Knowledge (Alpha)

Turns what the workflow parses into a searchable knowledge base. Add a Knowledge step and every document the workflow runs is folded into a per-workflow corpus you can browse, search, and ask questions of — with answers cited back to the page they came from.
  • You configure: nothing. Its presence is the switch.
  • Add it when: the documents themselves have lasting value, not just the fields you pull out of them — contracts you’ll need to search later, policies your team asks questions about, anything you’d otherwise paste into a separate tool.
  • Where results show up: the Knowledge tab in the app.
Example: every contract the workflow processes becomes searchable, so “which suppliers have a 90-day termination clause?” is answerable with citations.
Indexing only bills for pages whose content is new or changed, so re-running a workflow over documents it has already seen adds nothing to your bill. Browsing and searching are free.
The API can add a Knowledge node to a workflow, but reading the corpus is not exposed through the API yet — no browse, search, or ask operations. Until they ship, the knowledge base is consumable in the app only.

​
What’s next?

Using Studio

Open Studio, add steps, and connect them

Field types

The kinds of values an Extract step can return