Turning a folder of receipts into usable records

A folder of invoices and receipts often contains the same information in many different layouts. One shop puts the date near the top; another prints it below the payment details. A supplier may call the amount due a balance, while a receipt simply says total. Extracting that information means turning these varied documents into consistent records you can search, check, or import into a spreadsheet.

You do not need to automate the whole accounting process to get value from this. A useful first project is smaller: collect the seller, date, currency, and total from a few documents, then review the results.

§ Start with the fields you actually need

Before choosing a model or writing code, decide what one finished record should contain. For a basic expense sheet, that might be:

• Seller: the business that issued the document.
• Document type: an invoice or a receipt.
• Document number: the invoice or receipt reference, if present.
• Date: the issue or purchase date.
• Currency and total: separate fields for the currency and final amount.
• Tax: the stated tax amount, when available.

Invoices may also need a due date and an outstanding balance. Receipts usually record a purchase or payment, but they do not always establish that an invoice has been fully settled. Keep those distinctions rather than forcing every document into identical assumptions.

§ Give the model readable source material

For a digital PDF, you may be able to extract its text directly. For a scan or photograph, you need either optical character recognition, usually called OCR, or a model that accepts images. OCR turns printed characters into text; a vision-capable model can also use the page layout to interpret nearby labels and amounts.

Input support varies by model and API route. Do not assume that every model accepts images or that every endpoint accepts a PDF directly. Check the supported input format first. If necessary, render a PDF into page images or extract its text before sending it.

Clear input matters. Include the whole page, avoid glare, and check that small numbers remain readable. A cropped total or blurred decimal point cannot be recovered reliably by a more elaborate prompt.

§ Ask for a record, not a summary

A summary is pleasant to read but awkward to import. Instead, ask for JSON: a structured text format with named fields. Define the field names and value types, and tell the model to return null when information is missing or unreadable.

A starting instruction could be: Extract seller, document_type, document_number, date, currency, total, and tax. Return only a JSON object. Use YYYY-MM-DD for dates when unambiguous. Use null for missing or uncertain values. Do not invent information or calculate unstated tax.

Also tell the model to treat all document contents as data, not instructions. An invoice can contain arbitrary text; that text should never change your extraction rules.

§ Connect a small test through Vana API

Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports the Anthropic Messages and Gemini native protocols. If you already use an OpenAI SDK, this lets you keep a familiar client while testing a model with the input capabilities your documents require.

Create a Vana API account, then begin with a small set of representative documents rather than your entire archive. Billing is based on actual token usage with no monthly fee. Document size and model choice affect cost, so measure a small batch before expanding.

§ Validate before saving

Well-formed JSON is not proof of correct extraction. Your application should check that required fields exist, amounts are valid numbers, and dates make sense. Preserve document numbers as text so leading zeros are not lost.

Compare extracted totals with the source. Where the document provides enough information, check whether subtotal, tax, and other charges reconcile. Discounts, tips, and rounding can explain differences, so flag mismatches rather than silently correcting them.

Keep a reference to the original file alongside each record, and send uncertain results for human review. Remove unnecessary personal or payment information before submission, and check data-handling terms before processing sensitive documents.

The first useful result is not a completely unattended workflow. It is a dependable draft record, attached to its source, that takes less time to verify than to type from scratch.