Map source evidence to destination fields
Supply representative documents and a field specification. Mark required values, permitted formats, reference lists and whether blank means unknown or intentionally empty. Preserve identifiers that connect every output to its source.
Check before committing records
Validate dates, identifiers and dependent fields before import. Route illegible text or conflicting source versions to an exception queue; do not infer an identity or overwrite an existing value without an approved rule.
Price the accepted unit
Assess field count, source readability, system interaction and checking effort using a pilot. Agree whether a payable unit is an accepted row, document or task, and how source changes and rework are treated.
Make the field dictionary executable
For each destination field, specify the source location, data type, permitted transformation and failure action. “Enter date” is incomplete: an operator needs to know whether 03/04/2027 means 3 April or March 4, which source locale controls, and whether the destination stores a date or text. Preserve identifiers such as 00128 as text when leading zeros carry meaning.
Distinguish a source blank, an unreadable value, a value outside the permitted range and a field that does not apply. Those conditions require different follow-up. A separate exception code allows the business to request a clearer scan without mistaking missing evidence for a deliberately empty destination field.
Illustrative example: five fields from a scanned registration
In this hypothetical example, form F-028 is a two-page UK-format registration. The destination requires an account ID, received date, requested start date, contact name and quantity. The dictionary says dates are DD/MM/YYYY at source and YYYY-MM-DD at destination; names are transcribed without expansion. The received date 03/04/2027 becomes 2027-04-03. The requested start date is blurred and must remain pending.
The operator records page references, validates quantity as an integer and submits a draft record with exception EX-028. The client’s registration owner supplies a replacement page showing 12/04/2027 and approves that evidence; the operator enters 2027-04-12. Acceptance requires all five checks, the replacement reference and a successful destination receipt. Guessing from another form would fail acceptance even if the guessed date happened to be correct.
| Destination | Source and rule | Result / action |
|---|---|---|
| account_id | Page 1: 00128; preserve text | 00128, no leading-zero removal |
| received_date | Page 1: 03/04/2027; DD/MM/YYYY | 2027-04-03 |
| requested_start | Page 2: unreadable; no inference | EX-028, then 2027-04-12 from replacement |
| contact_name | Page 1: A. Patel; exact transcription | A. Patel, no invented first name |
| quantity | Page 2: 12; positive integer | 12, validation passed |
Separate transcription errors from source problems
A wrong value copied from a readable source is a processing defect. A correctly flagged unreadable field is an input exception. Record both, but do not combine them into an accuracy measure that rewards guessing or penalizes transparent holds. Agree how field accuracy relates to record acceptance: one incorrect account ID can invalidate an otherwise accurate row.
Use critical checks for fields that route money, identify a person or trigger a downstream action. Review sampling may be suitable for some descriptive fields, but a sampling plan does not remove the need to define high-consequence checks. Return corrections with old value, corrected value, source reference and defect reason.
Prove the destination received the intended records
Validate a prepared file separately from its import. Destination systems may reject duplicates, truncate text or reinterpret dates despite a locally valid spreadsheet. Retain the submitted batch ID and row-level result. Match successful, rejected and pending rows back to the original source count before declaring delivery complete.
For retries, reuse a stable external record key and check whether the first attempt wrote anything. Re-uploading the whole batch after a timeout can create duplicate records. The handover should identify which rows are safe to retry and who authorizes updates to existing records.