Linda Builds
Inside document workflows: separate the source file, extracted data and approval
Version source artifacts, extracted/proposed values and human/workflow decisions separately so document automation remains traceable.
When OCR or AI reads an invoice and produces supplier, date, amount and tax fields, users may only see a completed form and an Approve button. If values are corrected without source/extraction history, later review cannot tell what the document said, what the system misread or what the person changed.
This article describes a Linda document-workflow design principle. It does not certify that Acc Doc, Acc Flow or every Linda application already exposes every capability described; actual module/version scope must be confirmed.
Layer 1: preserve an identifiable source artifact
The source layer is the actual file, image, PDF or message received, together with source ID, file hash or immutable reference, received time, sender/channel and appropriate access policy. Do not replace the original when OCR is rerun or a user edits a field.
If a file is transformed for preview or compression, distinguish the derivative from the original and preserve the relationship. A reviewer should know which representation was displayed when making a decision.
Layer 2: keep extracted and proposed data separate from approved data
Where supported, retain extracted value, location/confidence or evidence reference, model/parser version and processing time so reruns can be compared. If the system proposes account or tax mapping, keep that as a proposal rather than presenting it as a fact written on the source.
NIST AI RMF is a voluntary framework organised around Govern, Map, Measure and Manage. The applicable design lesson is to define what the model does, measure failures and manage risk before increasing authority; referring to the framework does not mean NIST certifies a Linda workflow.
References: [1]
Layer 3: keep human and workflow decisions as append-only history
When a reviewer changes amount, supplier or classification, retain the approved value, decision actor/time, referenced source/extraction version and reason where policy requires it. Do not edit the extraction to make it look as though the system was correct from the beginning.
If approval has several scopes—document review, accounting review, payment approval—record each decision separately. A single Approved label should not hide what was actually approved.
Reprocessing with a new OCR/AI version must not erase the earlier decision
When a parser or model changes, create a new extraction version and compare it with the version previously reviewed. Do not automatically change approved accounting values merely because a newer model now predicts something different.
Keep previously corrected failures as regression cases. Decide which historical reruns are for search/enrichment and which could affect downstream transactions only after a new human review.
The product UI should make clear which layer the user is viewing
Linda lists Acc Flow and Vertex applications as its own software while requiring module, permission and handoff confirmation before onboarding. A document-workflow demonstration should therefore show, for a real or test document, how source, extracted fields, corrections and approval history are exposed in the actual product scope.
UAT should include OCR error, duplicate file, replaced source, manual correction, reprocessing under a new model version and downstream export after approval to verify that source/extraction/decision lineage survives the workflow.
References: [2]
A practical starting checklist
- Preserve source artifacts with stable identity/hash/reference.
- Version extraction/proposals separately from approved values.
- Keep append-only decision history with actor, time and scope.
- Create a new extraction version when OCR/AI is rerun.
- UAT source, extraction error, correction, reprocess and downstream export.
Apply it to your business
Document automation does not have to read everything perfectly to be trustworthy. It must make failures explainable by preserving what the source contained, what the system proposed, what a person changed and which result was actually used.
References
- National Institute of Standards and Technology. (n.d.). AI Risk Management Framework. Retrieved October 1, 2026.
- Linda Accounting IT. (2026). Linda Business Applications. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.