How Recognito works

Five things to internalize before you configure anything: how projects scope your work, how field categories really behave, why a document has two status tracks, what the Mapping rule engine does, and how data leaves Recognito. Five minutes.

This is the anchor page for everything else in the docs. If you understand the five sections below, every UI screen and every API endpoint will make sense.

1. Projects scope everything

Every customer creates one or more projects inside their organization. A project pins down:

• The document type it processes — Invoice, Receipt, Handover & Acceptance Certificate, or a custom model.
• Its field schema — what fields the engine extracts, what categories they belong to, what validation runs.
• Its mapping rules — entities, definitions, workflows.
• Its users and their roles — who can review, who can approve, what each person sees.
• Its integrations — webhooks, exports, mailbox address.

There is no per-project config above the project level. Each project is self-contained. The few things that live at the org level instead:

• API keys — at Settings → Organization → API Keys (org-owner only).
• Members — at Settings → Organization → Members. Per-project role assignments still happen inside each project.
• Billing — at Settings → Organization → Payments.

Everything else — fields, mapping, users, integrations — is per-project.

When to use a separate project

Each project has one field schema, one Initial_Workflow, one mailbox, and one response schema. Split work into separate projects when those differ — a different document type, a different downstream integration, or a separate group of users. You don't need a project per country or per vendor: Mapping handles those differences inside one project.

2. Field categories are conventions, not boundaries

Every Invoice project ships with five field categories:

Category	Convention
Main	Primary fields (invoice number, total, dates, …)
Table	Line items
Payment	Bank account, IBAN, due date, …
Tax	Tax rate, tax amount, VAT codes, …
Metadata	Vendor name, project name, GL accounts, departments, …

The recommended convention is: Main / Table / Payment / Tax fields come from the document (extracted by the engine), Metadata fields come from your reference tables (filled in by Mapping lookups).

Architecturally, there are no rules. Any field in any category can be either extracted or Mapping-fed. Real configurations often mix the two:

• A Main field might be Mapping-fed if your vendor master spells the name differently from the document.
• A Metadata field might be extracted if you have a custom field that doesn't fit the standard categories.
• The Table category routinely mixes both — extracted Quantity and UnitPrice alongside Mapping-fed erpItemCode and glAccountName.

Most public phrasing in these docs follows the pattern "by convention X, but the system supports Y." That flexibility is the most-misunderstood part of the product.

3. Documents have two status tracks

Every document carries two independent statuses. Understanding which one answers which question saves a lot of confusion later.

Track	States	Question it answers
Document Status	Processing → Done → Exported, plus the Needs action branch	Has the system finished its work on this?
Approval Status	Pending → Validated → Approved, plus Rejected and Duplicate branches	Has a human signed off on this?

These are independent. A document can be Done (extraction finished) and still Pending (no human has touched it). It can be Exported (sent downstream) and Approved (signed off). It can be Done and Rejected (extracted fine but rejected on business grounds).

The Needs action Document Status sits before Processing. Recognito sets it when a document exceeds the project's auto-scan page threshold — you open the document, click Process, and pick which pages to actually scan. This guards against accidentally running a 200-page PDF through OCR.

The Documents view shows both columns. The Approval Status filter strip at the top filters by the human-track status; the Document Status column shows the technical-track status.

4. Mapping is the rule engine

Raw extraction is one half of what Recognito does. The other half is Mapping — the rule engine that fires after extraction and turns raw fields into ERP-shaped, business-ready data.

Mapping has three layers:

• Entities — user-defined tables of reference data. A Vendors entity might have columns vendorId, name, taxId, bankAccount. A GLAccounts entity holds your chart of accounts. Entities are pure data; they have no behavior.
• Definitions — reusable lookup rules. A definition says "match the document's vendorTaxId against Vendors.taxId, then write the matching row's name to the document's vendorName field."
• Workflows — ordered chains of definitions plus a trigger event. "When this document is analyzed, run these three definitions in order."

Two trigger types exist:

Trigger	Fires when	Workflow that uses it
Document Analysed	The engine finishes extraction	The project's Initial_Workflow (one per project)
On field select	A reviewer interacts with the trigger field — picks a new value or edits it	Every other workflow you create

Three rules govern every cascade:

• Workflows don't trigger other workflows. A step that writes to a field updates that field but does not fire the workflow watching it. To chain logic, put all the steps inside one workflow.
• Steps inside a workflow run in declared order, and later steps see writes from earlier steps. This is how composite lookups work — step 1 sets vendorAccount, step 2 uses vendorAccount as part of its context.
• An empty entity cell never overwrites the document. If your matched row has currency=GBP but accountant=(empty), the document gets the currency update but keeps whatever accountant it had.

Don't try to memorize the engine. The summary above is enough to know that Mapping exists and what shape it takes. Read the Mapping & Workflows section when you sit down to write actual rules — the details earn their depth then.

5. Data leaves through outbound integrations

Once Mapping has done its work — fields populated, vendors matched, approvers routed, sign-off received — the document leaves Recognito. Several channels exist; you pick whichever fits your downstream stack.

Channel	Best for
Webhook	Real-time push to your ERP, BI tool, or anything that accepts HTTPS POST
Make.com node	Low-code automation pipelines on Make.com (the node is Recognito-built, hosted on Make's app store)
n8n node	Low-code automation pipelines on n8n (the node is Recognito-built, hosted on n8n's nodes catalog)
REST API pull	Custom integrations polling for approved documents
Clipboard / CSV / Excel / Print	Manual export for orgs that paste data into their accounting software

The payload shape is yours to control. The Custom Response Schema in Settings → Developers reshapes the canonical Recognito JSON into whatever your ERP expects — SAP, NetSuite, Microsoft Dynamics, a homegrown system. Your ERP doesn't change; the schema absorbs the difference.

Make.com and n8n nodes live on those platforms

The Make and n8n nodes are configured inside Make and n8n, not in Recognito's Settings → Integrations. Recognito ships the node; you add it to a Make scenario or an n8n workflow and paste an API key. There's no Recognito-side card to enable.

What's next

• 5-minute quick start — upload your first document and see the whole flow end-to-end.
• Account setup — sign in, switch organizations, update your profile.
• Using Recognito — the daily reviewer flow: filtering documents, validating fields, approving.
• Configuring Recognito — the admin flow: projects, fields, users, capture channels.
• Mapping & Workflows — the rule engine in depth.