Getting email and PDF receipts into the same system

A receipt that arrived as an email or a PDF is easier to extract from and harder to file than a photographed one. The text is already text, so recognition is not a step. But the same purchase now generates several documents from several channels, and the duplicate problem gets meaningfully worse rather than better.

The goal is one system holding every receipt regardless of how it arrived. Getting there is mostly about deciding which arriving document is the record, and rejecting the rest.

Three kinds of “digital receipt”, and they behave differently

A text PDF. The characters are embedded in the file. Extraction reads them directly, with no recognition step and therefore no recognition errors. Layout ambiguity remains — knowing which number is the total is still a judgement, and that is the extraction problem, not the reading problem.

An image-only PDF. A scan or a photo in a PDF wrapper. Looks identical in a file listing and behaves exactly like a photograph: it needs recognition, and image quality decides whether it works. Many tools do not tell you which of the two you have, and the practical symptom is a PDF that inexplicably extracts worse than its neighbours.

An HTML email. Text, but structured as a marketing layout rather than a document. The amounts sit in table cells alongside promotional copy, unsubscribe links and loyalty balances. Extraction from these is often worse than from a clean photograph of paper, because there is far more plausible-looking numeric text to choose from.

The important consequence: “digital original” does not mean “reliably extracted”. It removes one error source and leaves the rest.

The forwarding address, and what breaks it

Most systems offer an address you forward receipts to. It works well and fails in a small number of specific ways worth knowing in advance.

Forwarding wraps the original. Your client may quote the email as text, attach it, or inline it depending on the client and how you forwarded. Quoted text loses the attachment; the ingesting system then has a body full of > characters and no document.

Threads arrive as one message. Forwarding a conversation that happens to contain a receipt delivers several documents’ worth of text, and the system picks one. Forward the individual message, not the thread.

The attachment may not be the receipt. Some vendors attach a branding image and put the receipt in the body; others do the reverse. A rule of “always take the attachment” is wrong roughly as often as it is right.

Auto-forward rules catch too much. A filter on the word “receipt” will pull in every marketing email that uses it. Filter on sender where you can, and expect to maintain the list.

Order confirmation, invoice, receipt

An online purchase commonly produces three emails: a confirmation when you order, an invoice, and a payment receipt or dispatch note. Some carry the same total; some do not, because shipping was added or an item went out of stock and the charge changed.

Ingesting all three gives you three records of one purchase with two different amounts, which is worse than missing one entirely — you now have a discrepancy to investigate that never existed.

Decide which document is your record and take only that. Usually it is whichever states the amount actually charged, which is the one that will match your card statement. That principle makes reconciliation against the bank feed the arbiter, and it is a better arbiter than any preference about document titles.

Duplicates arrive from more directions now

With paper, a duplicate meant you photographed the same slip twice. With mixed channels the paths multiply: the emailed receipt and a photo of the printed copy handed to you in store; the auto-forward rule and your manual forward of the same message; a monthly subscription invoice that also appears in the vendor’s account-summary email.

Matching is also harder, because the vendor name on an email receipt is often the marketing name while the statement descriptor is the billing entity — the familiar vendor-name problem in a sharper form. Match on amount and date first, and treat the name as corroboration.

None of this changes the right response, which is to surface the pair with both documents visible and let a person decide, exactly as with photographed duplicates. It just means you should expect more pairs than you would from paper alone, and configure accordingly rather than concluding the matching is broken.

Keep the file, not a rendering of it

An email receipt has a body, headers, and possibly an attachment. A system that stores a screenshot of the rendered body has thrown away the headers — the sender, the timestamps, the message identifier — which are the parts that establish where the document came from.

Store the original file. A PDF stays a PDF; an email is worth keeping as an email. The reasoning is the same as for choosing a format for scans: the original capture is the evidence, and anything derived from it is a convenience you can regenerate.

A setup that works

One inbox for everything. Photos, forwards and PDFs land in the same queue and go through the same extraction, review and posting path. Two parallel workflows means one of them will be neglected.

Filter by sender, not by keyword. Fewer false positives, and the list of vendors who email you receipts is shorter than it feels.

Forward single messages. A habit, not a setting, and the one that prevents the most confusing failures.

Expect the duplicate queue to be busier. Tune the matching, do not switch it off.

Check what happens to the file. Ask once, early, whether the tool keeps the original document or only its extracted fields plus a preview. The answer determines what you have in three years.