Receipt and invoice OCR: turning paper spend into data

It is 9:40 p.m. on the fourth of the month. The person who handles bookkeeping has spread fifty-six receipts across a kitchen table: eight fuel slips, two courier dockets, one stationery invoice, four toll receipts and three lunch receipts whose edges have already started to fade. A blank spreadsheet is open, the cursor blinking in the "Supplier" column. The numbers here are an example, but the table is familiar. The money has already left the account and the spending has already happened; the only thing missing is a row that records it. Until that row exists, the business does not know its own cost base — it only knows its balance went down.

This article walks through the job of turning paper spend into data. It starts with why receipts disappear at the same point every month, then explains what an optical character recognition (OCR) engine actually extracts from a receipt. From there: how much photo quality changes the outcome, whether extracted data should land as a draft or a final record, which fields you can hand to the machine and which need a human, how document types differ, how foreign-currency spend is handled, how OCR divides work with structured e-invoices, how staff out-of-pocket spending fits in, how month-end reconciliation works, and a thirty-day rollout plan. Wherever regulation is involved, one rule holds throughout: this is a description of a workflow, not tax or legal advice.

Why do paper receipts always vanish at the same point?

A receipt usually passes through three stops: the moment of the purchase, a limbo period in a pocket or glovebox, and the late evening at month-end when someone tries to gather them all. Most of the loss happens at the second stop. Even when the paper survives, the context does not: which client visit that fuel was for, which order that courier fee shipped, which team that lunch fed. The paper carries only an amount and a date; the information that justified the spend lives in the buyer's head, and two weeks later it is gone from there too.

The second problem is the delay itself. Book an expense thirty days after the purchase and the record is still correct, but it is no longer useful. Mid-month you cannot answer "where is cash going this month", because half the month's cost has not reached the system yet. Late expense entry is not an accounting problem; it is a management problem. That is exactly where the value of keeping income and expense visible in near real time shows up: being right is not enough if the number arrives after the decision.

The third problem is that data entry is the dullest task in the office, so it is the most deferred one. Typing fifty-six receipts by hand is monotonous, attention-heavy and unrewarding. The longer it waits, the bigger the pile; the bigger the pile, the longer it waits. What OCR really solves is not typing speed but this accumulation loop: a job that takes thirty seconds at the point of purchase never becomes a four-hour evening at month-end.

What does OCR actually pull off a receipt?

Reading a receipt is more than converting an image into text. The engine works in two stages: first it turns pixels into characters, then it decides which piece of that text belongs in which field. The second stage is the hard one, because a receipt can show three numbers side by side — net, tax and gross — and choosing the one that belongs in the expense line is a semantic decision, not a formatting one.

In Rocketly's pre-accounting module, Smart Receipt Reading (OCR) connects that second stage to the expense form: you photograph a receipt or an invoice, and the supplier, date, VAT and amount are read and used to fill the expense form for you. The important distinction is that the feature fills the form; it does not approve the record on your behalf. The machine produces a proposal, a person makes the call. That single distinction is what keeps the whole workflow safe.

In practice the extracted fields are not equally reliable. The gross total is printed largest and in the most predictable position, so it is the easiest to read. Dates are usually captured but bring format trouble: day/month order, two-digit years, a time stamp bleeding into the date. Supplier names sit at the top of the slip, yet the trading name and the legal entity name are often different, and which one belongs on your contact card depends on how you keep your ledger. VAT is the most fragile field of all: a single supermarket receipt can carry two different rates, and if the engine flattens them into one line the resulting expense is wrong. It also helps to be clear about how document types differ in the first place — the basics of issuing invoices correctly are worth a separate read.

How much does the photo itself change the result?

Most complaints about OCR quality are complaints about input, not about the engine. Thermal paper fades with heat, sunlight and friction; the top half of a receipt that lived in a wallet for two months can be unreadable. No amount of software fixes that. The fix is taking the photo on the day of the purchase.

The habits that actually help fit in a short list:

• Put the receipt on a flat, plain surface; a patterned tablecloth confuses edge detection.
• Keep your own shadow off the paper; shoot at a slight angle rather than straight down under a ceiling light.
• Photograph the whole slip unfolded and fully inside the frame; a cropped bottom edge usually means a cropped total.
• One document per frame; three receipts laid side by side can be read as a single expense.
• Flatten curled till rolls; a wavy surface breaks line alignment and shifts number columns.

Rather than enforcing these as rules, it works better to make capture-at-purchase effortless. Taken thirty seconds after paying, the receipt is clean, the light is usually decent and the context is still in the buyer's head. Taken three weeks later, all three of those problems arrive at once.

Should the extracted receipt land as a draft or as a posted record?

This is the most important design decision in an OCR rollout. Writing extracted data straight into balances and reports looks fast, but one misread total quietly corrupts the month-end view. The right pattern is to hold machine output in a waiting area and attach the financial effect to human approval.

In Rocketly that separation is built with Financial Drafts: collections and payments can be saved as drafts without touching balances, the draft queue sits in its own workspace so an unprocessed entry never distorts a contact's balance, and once the information is complete the entry is converted into a posted movement in a single action. The practical result is that every line OCR produces starts as pending and only reaches reports after someone has looked at it. You keep the speed without paying for it in accuracy.

An approved expense then lands with its category. On the Expense Management and Categories side, supplier invoices, category-based tracking, VAT and due dates are held together, and payment status plus expense-payment reports show where the money went. OCR can guess a category, but the guess is based on the supplier name — and the same shop can supply both office stock and client refreshments, so a person should confirm it. When the bookkeeping side and the sales side need to stay in step, we covered how invoice sync ends double data entry separately.

Which fields can you leave to the machine, and which need a human?

Checking every field with equal care hands back the time OCR saved. The goal is not to remove review but to concentrate it where errors actually occur. The split below works as a draft internal rule; set your own thresholds according to document volume and what your accountant expects.

Field	What the machine does	Where it slips	Suggested check
Gross total	Read with the highest accuracy	Cropped bottom edge, duplicate total lines	Glance check; reshoot if it looks off
Date	Read and normalised to a format	Day/month order, two-digit years, time bleed	Always verify near a period cut-off
Supplier	Extracted from the header text	Trading name versus legal entity name	A person confirms the contact match
VAT rate and amount	Attempts to split it out	Multiple rates on one slip, withholding cases	Human verification every time
Expense category	Inferred from the supplier	Different spend types from the same supplier	Keep the choice on the approval screen

The logic is simple: machines read formatting well and judge meaning poorly. An amount is formatting; a category is meaning. So the time saving comes from amounts and dates, while quality is preserved by keeping a person on categories and tax.

If a till receipt is not an invoice, how does the expense record change?

To an OCR engine a till slip and a supplier invoice look alike; both carry a date, an amount and a tax figure. To accounting they are different documents, and how each one is treated depends on the document type and on the situation of the business. The regulatory half of that question is deliberately outside this article: which document can support an expense, and under what conditions a cost is deductible, is something to confirm with your accountant. What belongs here is how the document enters the system, how it is labelled and whether it stays findable.

As a practical rule, have the person choose the document type at upload instead of letting OCR infer it. Receipts, supplier invoices, bank advices and payment vouchers follow different paths: one creates an expense line, another only settles a payment. The same document entering through two different doors and creating two records is the single most common cause of duplicated cost. Non-binding documents deserve the same care; knowing where a proforma parts ways with a real invoice prevents the wrong paper from being booked as an expense at all.

Keeping the image attached to the record matters as much as the data. If the photo of the slip sits next to the expense line, a question raised months later closes in three minutes. When the image and the record live in separate places, proving the entry becomes work even though the data is right. For how long documents must be retained, follow your accountant's guidance rather than general commentary you find online.

Which exchange rate applies to a foreign-currency receipt?

Overseas software subscriptions, flights, hotels and conference fees arrive denominated in another currency. Even when OCR reads the amount correctly, the question of which rate to use remains, and the answer differs by moment. The rate on the purchase date, the rate on the posting date and the rate on the day the payment cleared can all differ. On one small line the gap looks trivial; across a year of recurring subscriptions in USD, EUR or GBP it adds up to a number worth knowing.

On the Rocketly side, Multi-Currency with Central Bank Rates pins that decision to the record: documents can be issued in USD, EUR, GBP and more, the rate at the time of the document is stored, and the amount is converted into your base currency using the daily published central bank values. The key point is that the rate is stored with the entry, so months later "which rate did this line use" is answered from the record rather than from memory. We went deeper into the bookkeeping side of this in the piece on working in foreign currency and handling exchange differences.

One warning: leaving the rate field empty on a currency entry does not only affect that line, it removes it from reports. Currency items without a stored rate are excluded from the cash flow projection, and the screen says so explicitly. It is a visible warning rather than a silent gap — but reading the warning is itself a habit.

If e-invoices arrive automatically, why is OCR still needed?

For purchases inside the electronic document chain you do not need OCR at all; the data already arrives structured. In Rocketly, Expenses from Incoming e-Invoices uses that directly: you give a date range, your purchase e-invoices become draft expenses, and each document is imported once against its unique document reference, so no duplicate record is created. There is no such thing as a reading error in this path, because what is processed is a field-level document rather than an image.

OCR covers everything outside that chain: till receipts, parking and toll slips, small cash purchases, some supplier invoices that still arrive on paper, and documents from abroad that never enter the local e-document system. The two are not competitors but two branches of the same pipeline. Knowing in advance which document arrives through which branch is what saves the most time during setup, and clarifying the difference between an e-invoice and an e-archive invoice is the first step of that split.

The ratio between the two branches shifts over time. As electronic document coverage widens, OCR's share shrinks, but it never reaches zero: small, immediate, paper-bound purchases persist in every business. Track when the scope changes for your own company; the article on how mandate timelines and turnover thresholds work gives the framework, and your accountant confirms where you personally stand.

How does staff out-of-pocket spending enter the flow?

In businesses with field teams, most receipts do not belong to the back office at all; they come out of a technician's, a rep's or a courier's own pocket. That creates two separate problems: an expense to record and a debt to an employee. Without a system that separates the two, month-end turns into reconstructing "who do we owe what" from chat messages.

In Rocketly, Employee Out-of-Pocket Spending handles that second leg: expenses paid personally by staff and their reimbursements are tracked, and an employee statement shows exactly who is owed how much. Combined with OCR the flow simplifies to five steps: the person who paid photographs the receipt, the entry lands as a draft, the back office confirms category and tax, a debit line is added to the employee statement, and the line clears when reimbursement is made.

One rule is enough to make this stick with a team: no photo, no reimbursement. It sounds strict, but it is easy to comply with, because taking the picture costs thirty seconds at the counter. The alternative is arguing at month-end about who remembers a receipt that no longer exists.

How is OCR data reconciled with bank movements at month-end?

Reading receipts does not close a month on its own. Every captured expense corresponds to a payment, and that payment has to match a bank or cash movement. Without matching, two familiar errors appear: the same purchase entered twice, once from the receipt and once from the bank line, or a bank outflow with no receipt sitting uncategorised.

Two features work together at this step. Bank Statement Import lets you upload the statement CSV, preview the parsed lines and turn them into cash movements, with repeated lines skipped. Bank and Cash Reconciliation then compares movements using automatic matching suggestions, you approve them, and you close the remainder manually. That remainder is the most valuable list you will see all month: every unmatched line is either a missing receipt or a misread amount.

Corrections also surface at close. When an expense was booked to the wrong supplier, entered twice or captured with a wrong amount, the route you take depends on the document type; we covered when cancellation is appropriate and when a correction is in a separate article.

How entries flow into statutory books is a different field again; a general grasp of how electronic ledgers work and who keeps them is useful, but confirm your own obligations with your accountant.

What does a thirty-day move from paper to data look like?

Teams that try to switch in one move usually slide back to the old habit in week two. A staged plan holds better. In week one, start with a single expense category — fuel, for example. One category, one person, one flow: photo, draft, approval. The goal that week is not volume; it is seeing the loop work end to end.

In week two, open it to the team and note which field gets corrected most often at approval. Usually it is VAT or category; whichever it is, concentrate your review energy there. In week three, bring in electronic documents: turn purchase e-invoices into draft expenses and view them in the same queue as the OCR-captured paper, then check that nothing has been booked twice. In week four, import the bank statement, run reconciliation and close the unmatched lines one by one. At the end of the month you hold two outputs: an expense table with verified categories, and a short list of what is still stuck on paper.

Once the loop is steady, looking forward becomes possible. Cash Flow Projection carries expected inflows and outflows forward by due date: open invoices, expenses, recurring items and portfolio cheques and notes enter the projection across the number of weeks you choose, with overdue and undated open items flagged separately. If your expenses are not captured on time, that projection reads optimistically — which is where the real return on OCR becomes visible. If you also push invoices into an external accounting system, the article on setting up invoice and contact-account automation describes the next step.

To try it with your own documents, open a Rocketly account and run a few receipts through the flow with your own data.

FAQ

Can OCR read a faded thermal receipt?

Partly. If a section of the print is fully gone, the engine cannot invent the missing field; typically the total is read while the supplier or tax line stays empty. That is why the standing recommendation is to photograph on the day of purchase. You can complete the unread fields manually and then convert the draft into a posted movement.

Does an OCR-captured expense hit reports immediately?

By design, no. Extracted data waits as a draft, and because the draft queue lives in its own workspace, an unprocessed entry never distorts a contact's balance. The record becomes a posted movement, and enters reports, only after approval.

What happens if I upload the same receipt twice?

For image uploads, the approval step catches it: the draft queue shows the same supplier, date and amount side by side, and the duplicate is deleted before it is processed. For expenses generated from incoming e-invoices, each document is imported once against its unique reference, so re-running the import does not create a second record.

How long do I need to keep the paper receipts?

Retention periods depend on document type, on your business situation and on the rules in force, and this article deliberately does not state a duration. Confirm your own obligation with your accountant. What is clear on the system side is simpler: keep the image attached to the record, and never let the archive drift away from the entry.