Appearance
Payment, Tax, Metadata
Three categories with distinct conventions but identical mechanics. Payment for bank and IBAN-shaped fields, Tax for tax codes and amounts, Metadata for everything Mapping populates.
This page covers what each is for, what lives in each by default, and the practical decisions about adding custom fields.
Payment fields
The Payment category holds fields related to how an invoice gets paid — bank accounts, payment methods, due dates.
What Payment fields look like in practice
Payment fields are payment-instruction fields the document carries — bank account details, IBAN, payment method, due date, payment terms. Some come directly from the document; others (like canonical payment terms) are often Mapping-fed from a vendor master. Your project's exact Payment fields depend on its extraction model and what your team has added.
When to add a custom Payment field
Reach for Payment when the field is part of the payment instruction the document carries. Bank-routing details, payment-related metadata, anything an accountant cross-references against the payment system.
If the field is more about classifying or routing the document for approval rather than paying it, Metadata is usually the better home.
Tax fields
The Tax category holds tax-related fields — rates, amounts, codes, classifications.
Typical Tax fields
Tax projects commonly include fields such as a tax rate, total tax amount, VAT or tax registration codes, and jurisdiction identifiers for cross-border invoices. The exact fields depend on your project's extraction model and what your team has added — check Settings → Document fields to see what your project shipped with.
Tax fields are heavily extracted in straightforward jurisdictions and often Mapping-fed in complex ones (Polish split-payment rules, Lithuanian local tax codes, etc.).
When to add a custom Tax field
Country-specific tax identifiers (NIP, REGON, KRS, etc.), VAT-classification codes, reverse-charge flags. Anything that lives next to the standard tax fields in a reviewer's mental model.
If the country's tax codes aren't in the default model, the standard pattern is:
- Add a custom Tax field with AI Post Processing.
- Write a clear AI Post Processing instruction mentioning the field label, format, and typical location on the document.
- Add a Mapping definition that validates or normalizes the extracted value against a country-specific entity if you have one.
Metadata fields
The Metadata category holds enrichment — values that come from your reference tables rather than the document itself.
Typical Metadata fields
Metadata fields are defined by your team — there's no fixed default list. Common examples include a canonical vendor name from a Vendors entity, a department or cost-center code, GL account entries, and an ERP vendor identifier mapped from the extracted tax ID. Your project's Metadata fields reflect your business logic and the outputs of your Mapping configuration.
Metadata is where most Mapping output lands. Reviewers expect to see business-logic-derived values here.
When to add a custom Metadata field
Most custom fields end up in Metadata. The rule of thumb:
- The value comes from a Mapping lookup — Metadata.
- The value is a business-process attribute (cost center, approval group, work order) — Metadata.
- The value is the reviewer's manual classification — Metadata (so the reviewer expects to fill it in).
Common Metadata patterns
| Field | Typical source |
|---|---|
erpVendorId | Vendors entity lookup on vendorTaxId |
glAccountName, glAccountNumber | GL Accounts entity lookup, possibly via vendor's defaultGLAccount |
costCenter | Department-specific lookup; manual fallback |
assignee | Vendor or cost-center driven |
approvers_N_M | Routing definition based on total, vendor, or department |
customerInitials | Discriminator value for group-of-companies projects |
Patterns like these compose with Mapping to turn extracted data into ERP-ready records. See Mapping & Workflows for the rule-engine side.
How the three differ
Mechanically, they don't. Each is just a visual group with its own document-lock setting. The differences are conventions:
- Payment — fields a payment system cares about.
- Tax — fields a tax authority cares about.
- Metadata — fields your business logic cares about.
The reason to follow the conventions: reviewers scanning a document already learned what to expect in each section. Putting a GL account in Payment confuses them.
Document lock for these categories
Like Main and Table, each of Payment, Tax, and Metadata has its own Document lock setting. Common patterns:
- Payment, Tax locked when Approved or Exported — these fields drive financial systems; you want them frozen after sign-off.
- Metadata kept editable longer — GL codes and department assignments sometimes need correction post-export. Many orgs leave Metadata unlocked or lock only on Exported.
See General settings → Document lock for the configuration.
A note on Automatic / Manual for these categories
The Automatic / Manual toggle on each field is legacy in every category, not just Main. It doesn't control behavior. Whether a field is extracted or Mapping-fed is determined by your Mapping configuration, not by this toggle.
What's next
- Field categories — the shared concepts behind all five categories.
- Validation rules — making fields mandatory across categories.
- Mapping & Workflows — the rule engine that populates Metadata fields.