Receipt data extraction: start with the fields your team needs

An accountant looking at a scanned receipt may need only one value for the task at hand. Another workflow may require several fields and a specific way of handing them to the next person. Before choosing an extraction approach, it helps to make that difference explicit.

Xinexis is developing Receipt Data Extraction around this practical starting point. The current prototype extracts the total amount from a scanned receipt. Additional fields and output requirements can be scoped for a customer's workflow, subject to development and validation.

What works today

The current capability is deliberately narrow: extract the receipt's total amount. The product is in development. It is not a self-service processing service on this website, and this website does not accept receipt uploads.

Merchant name, receipt date, currency and taxes are possible topics for a requirements discussion. They are not supported configurable features today. The same distinction applies to output formats and accounting integrations: these would need to be agreed, developed and validated.

That boundary gives a prospective customer a concrete question to consider: would extracting the total address a useful part of the team's work, or does the first useful version require something more?

Start with the next step in your workflow

Describe what happens after someone reads the receipt. Which person needs the information? What decision or record does it support? Where is it entered, and what happens if it is missing or unclear?

Use that description to separate essential information from information that would merely be convenient. A field belongs in the first scope when its purpose and expected use are clear. If nobody can explain what a field will be used for, leave it as an open question.

Describe the surrounding process as part of the requirements discussion. Responsibilities and any later connection to another system need their own agreement.

Make each field unambiguous

A request to extract “the amount” can hide different expectations. Write down which label or meaning the team intends, and how an unclear receipt should be handled. Include examples where more than one amount appears.

Consider a synthetic receipt that shows a subtotal of 40.00, tax of 2.80 and a total of 42.80. For a total-only requirement, the expected value is 42.80. These invented values illustrate a field definition, rather than a measured product result.

If currency is also needed, record it as a separate requirement. Do not assume that extracting 42.80 establishes the currency. Similarly, a future date field would need a clear definition of the expected date and its representation. These details make later validation more useful.

Choose examples that reveal the difficult cases

A useful evaluation set should reflect the receipts the team actually encounters. When planning it, consider readable and unclear scans, different layouts, partially visible text and receipts with several amounts. Agree which situations are inside the initial scope.

For each agreed example, a person should establish the expected total before evaluating the extraction result. Keep the source and expected answer connected so a disagreement can be investigated. An unreadable receipt should remain an explicit exception rather than receive an invented answer.

These are recommended evaluation practices, not claims about existing product controls. Begin a discussion with a description of the document types. Any later sample-sharing arrangement should be agreed separately, using an appropriate channel and material the organization is authorized to share.

Agree how people will check and use results

Decide who checks extracted values and what happens when a result is wrong or uncertain. A proposed workflow might require comparison with the source receipt before the value is used. The checking process would be agreed during scoping; a built-in review interface is not a confirmed capability.

Also describe the intended destination for the information. A team may have output requirements because of its existing process, but no particular file format or integration is currently promised. Discuss those requirements alongside the fields, rather than assuming the handoff will be automatic.

Acceptance criteria should describe observable results: the agreed value for each example, how exceptions are identified in the proposed workflow and who owns their resolution. Performance expectations need evaluation against an agreed scope; they should not be inferred from one successful example.

Bring a short requirements brief

A useful first conversation needs four things: the receipt information your team needs, how it will be used, the kinds of documents involved and the checks required before use. Include any essential output requirements and distinguish them from preferences.

Read the Receipt Data Extraction product overview for the current development status, then discuss your requirements with Xinexis. We can identify what fits the current total-extraction prototype and what would need further scoping, development and validation.