Define your fields correctly so Affinda extracts data exactly how you need it downstream.
Field configuration settings allow users to customize how data is extracted, processed, and displayed in Affinda’s platform. These settings ensure the extracted data meets specific requirements and can be easily integrated into downstream workflows.Field configuration options can be accessed by Workspace Owners and Admins by clicking ‘Configure Fields’ in the top right corner of the document validation view.
The field name represents the label for the extracted data in the validation UI. It is user-defined and helps the model in extracting the field from documents; as such, it is important to have clear and relevant field names.
Users may optionally enhance the model’s predictions by providing additional context, such as how the data is typically labelled and where it appears on the page.
Adding more documents is the recommended way to enhance model accuracy. However, a clear field description can also improve extraction results
Your field’s data type determines how extracted values are processed and standardized. Different data types are available to ensure that structured and unstructured data is correctly categorized. The selected data type influences the structure of the data and the post-processing logic applied to extracted values, ensuring consistency and accuracy.
If the raw data extracted from the document is unable to be logically parsed into a format consistent with the data type selected, no parsed value will be returned. Edit the annotation to improve extraction accuracy, or in the case where the bounding box is correct, edit the value directly by typing the correct value
This setting determines whether the field should be predicted and visible in the extracted output. Users can toggle this option depending on whether they want the model to extract and display the field.Disabling a field instead of deleting it lets the model keep all previously validated annotations and automatically restores them when the field is re‑enabled.
Enable multiple predictions only when a field can have multiple distinct values within a single document. Examples include:
Line item tables on an Invoice
Parties or Signatories in a Legal Contract
Transactions in a Bank Statement
Enabling multiple values where you would generally not expect multiple distinct values in a document can reduce model accuracy (by overpredicting values) or risk noise and confusion in review workflows due to the presence of duplicates.
Rule of thumb: if there should only be one real value (even if it appears multiple times on the same document), stick to a single value. Only enable multiple values when the document structurally allows or expects multiple distinct values.