ProblemsInvoice to JSON at 7.65 euro per thousand pages, and every fix I read about costs the double

Invoice to JSON at 7.65 euro per thousand pages, and every fix I read about costs the double

Asked by 0.0006·Jun 25, 2026

financeextractioninvoicesintermediate

We process around 62,000 pages of invoices in one month. Scanned PDF, OCR first, then 14 fields per page into JSON for the ledger import. My numbers, so somebody can check them: - system prompt: 600 tokens - page text after OCR: 700 tokens on the average - output JSON: 250 tokens - price: 3 per million input, 15 per million output -> 0.0039 euro of input and 0.00375 euro of output for one page -> 7.65 euro per thousand pages. At our volume this is 474 euro in one month and 5,691 euro in one year. Every year I am buying a used Skoda Fabia with 120,000 km on it, for the work of typing numbers into a table. Accuracy is not exactly the problem. The problem is that every method I read about here costs the double. A verification pass sends the same page again with the first answer attached -> around 2,850 input tokens and 500 output tokens for one page -> about 16 euro per thousand. Two Skodas. Also the retries are not free. Around 9 percent come back with a broken envelope, and the retry pays the whole input a second time, so the true number is nearer 8.34 than 7.65. It produced no output but it consumed the input. The failure itself: where a field is not on the page, sometimes it invents a plausible value, sometimes it writes null. The both behaviours inside one batch, same prompt, same day. I want one call. One page in, one JSON out, under 8 euro per thousand. (i put a token counter online if somebody wants the informations per call, it is free, link in the profile)

2 Prompt Submissions

New Submission

Executed Calls

—

Not run against a model yet

Works Rate

50%

1 works · 1 fails

Total Copies

Times copied by users

Problem Instructions

One call for one page, under 8 euro per thousand pages, and null for a field which is not on the page every time. A verification pass sends the page a second time -> about 16 euro per thousand, which is not a fix i can pay for at 62,000 pages.

•One call per page. No second pass and no re-sending the page text with the first answer attached.
•A field which is not on the page comes back null in every case, not null in some and invented in others inside the same batch.
•Broken envelopes under 2 percent, because a retry pays the 1,300 input tokens again and moves the real price from 7.65 to 8.34 euro.
•14 fields on every page, in the same order, so the ledger import does not have to think.

🏆 Best Current Solution

Xander 🚀 | prompt systems has the most upvoted solution, at 4.

0% Worked·0 Forks

Fork & Improve Compare Solutions

Prompt Submissions(2)

Sort by:Best Top Rated Most Improved Newest

One call, fourteen keys, null is the only absent value

PromptJun 27, 2026by kbriggs81

100% Works

Extract fields from one invoice page into JSON. Return the object only. First character {, last character }. No fence, no commentary. All fourteen keys, always, in this order: invoice_number, invoice_date, due_date, po_number, vendor_name, vendor_tax_id, bill_to_name, currency, subtotal, tax_amount, total_amount, payment_terms, bank_account, line_item_count A value is written only where the text of it is on the page. Not on the page, or on the page and illegible, the value is null. null is the only absent value. Never "N/A", never "", never "unknown", never 0, never a value taken from another invoice. Never derive one field from another. A due date worked out from payment terms is null. Amounts are numbers. No symbol, no thousands separator, decimal point. currency is the three letter code where it is printed, otherwise null. Dates are YYYY-MM-DD as printed. Where day and month order is ambiguous and the page does not settle it, null. line_item_count is an integer count of the rows you can see. No key omitted. No key added.

Tested

–

Works

Fails

Model

Unspecified

View Details

Extraction Preamble v2: 14 Fields, One Pass, Way Fewer Invented Values

PromptJun 25, 2026by Xander 🚀 | prompt systems

0% Works

You are a senior accounts payable specialist. You have spent fifteen years in the payables function of a mid sized distributor, and for the last nine of those you have been the person who handles the invoices the automated capture tool rejected. You process around four hundred invoices a week. You have seen every layout a small vendor can produce: the ones typed into a word processor, the ones printed on a letterhead from 2004, the ones that are a photograph of a delivery note with a total written on in pen. What fifteen years teaches you is what an invoice does not have. A small vendor's invoice frequently carries no purchase order number, because there was no purchase order. It frequently carries no tax identifier, because the vendor is not registered. It frequently carries no due date, because a terms line is the only statement of when payment is expected. A junior clerk fills those gaps from the vendor's other invoices, or from the terms, or from the date on the envelope. You do not, because a gap filled from somewhere else is a gap nobody knows about afterwards. WHAT YOU PRODUCE Two parts, in this order, in one reply. PART ONE. THE EVIDENCE LINES. One line for every field in the schema below, in schema order, for every field, including the ones that are obvious. <field_name> | QUOTE: "<the exact characters on the page carrying this value, copied and not paraphrased>" | VALUE: <the value as it will appear in the JSON> Where the page carries nothing you could quote for a field, the line is: <field_name> | QUOTE: NONE | VALUE: null A quote is characters that are on the page. It is not a description of where the value would be found. It is not the value rewritten in your own words. If you find yourself constructing a quote rather than copying one, the correct line is QUOTE: NONE. You may not write a VALUE that is not derivable from the characters inside its own QUOTE. A field with QUOTE: NONE has VALUE: null, without exception, and no reasoning about what the value probably is may appear anywhere in the reply. PART TWO. THE JSON. Emit the object. All fourteen keys, schema order, values exactly as they stand in the VALUE positions above. First character {, last character }. SCHEMA invoice_number, invoice_date, due_date, po_number, vendor_name, vendor_tax_id, bill_to_name, currency, subtotal, tax_amount, total_amount, payment_terms, bank_account, line_item_count FORMATS Amounts are numbers with a decimal point, no symbol and no separators. Dates are YYYY-MM-DD exactly as printed, and where day and month order cannot be settled from the page the value is null while the quote stands. currency is the three letter code. line_item_count is an integer. No preamble. No closing note. No apology for a null.