What this is for

Capture receipt handles the paper — a photo, OCR, a total read off the picture. This handles the other half: the card export, where four hundred lines arrive at once and none of them has an image. Both write the same ledger, so a period ends up with the receipts you kept AND the charges you did not.

Setting it up once

Open it from the pack and Recued guides you through it: choose the file, then match each field to one of the columns your export actually has. The choices are read from the file’s own header row, so nothing needs spelling. date, merchant and total are required — they are what tells one charge from another. The rest are optional; mark a field not in my file and it is simply not mapped. Tick Remember these columns and the next export arrives already matched.

From the plain run form instead, type the exact column names from your header row into the settings; the summary lists any it could not find in the file.

Give each card its own label. Every row's id is scoped to it, so the same amount on the same day at the same merchant stays two separate expenses across two cards, which is what they are.

Re-running is safe

Card exports overlap by design — the last statement period, every time. Each row's id is derived from its own date, merchant and total plus the card label, so importing the same export twice reproduces the same ids and adds nothing. The summary says how many you already had. Two identical charges on one day are still two rows: they are told apart by their position in the file, and a re-import walks the file the same way.

An imported row records its own content, never which upload carried it — the run's history keeps that, and there is no receipt image to point at. So the next export's repeated rows land as already had. ⚠ Rows imported by the first version of this importer were stamped with the file they came from, so a later export that repeats one counts it as kept, not already had — it is already recorded, and nothing is lost or doubled.

When an expense you already have looks different

Sometimes a row in the export is an expense you already have, but with different details — you categorised or reviewed it since, or chose a different period or currency this time. Keep what I already have starts ticked: those expenses stay exactly as you have them and are counted as kept. Untick it and the file wins instead: its tax, category and note replace yours — including a category you changed by hand — and the expense is counted as updated. The date, merchant and total are what make it the same expense, so they never change, and the period, currency and card come from you, not the file. The check shows you which it would be before you import.

Check first

The guided import always checks before it records. From the plain form, turn on Check first: Recued reads the whole file, puts every row through exactly the checks a real import would, then throws the result away and tells you what would have happened — including the first rows exactly as they would be recorded. Nothing is recorded.

Do this the first time you map a card. A column pointed at the wrong field imports perfectly — every row lands, nothing is refused — and the only sign is that the numbers are wrong.

What it does NOT do

⛔ An imported row is not checked against receipts you photographed. The importer cannot see them. Buy lunch on the card, photograph the receipt, then import the statement, and the ledger holds both — one from the picture, one from the card. duplicate_suspect is set by Capture receipt when it finds a match among captured receipts, and an import leaves it alone rather than guessing across two different kinds of record.

⚠ Everything lands as needs_review. An imported line has no receipt, no OCR and no category unless your export carried one, so it goes into the same queue a low-confidence capture goes into and Review expense clears it. Nothing is marked captured on the strength of a CSV.

⚠ Dates are stored exactly as your export writes them. 03/08/2026 stays 03/08/2026; reading it would mean guessing whether that is March or August, and a guess about dates silently reorders a year. List expenses orders by when Recued last touched the row and says so.

When a number or a date will not read

A number that cannot be read is stored EMPTY, never as zero, and the row still lands. A date that does not read in the format you typed is kept exactly as written. Either way the summary counts them and shows the first few with their line numbers, so you can open the file at that line.

Decimal marks and date formats

Both are under More options, and are remembered with your columns.

• Decimal mark. Pick Comma if your export writes amounts like 1.234,56 or 1 234,56. The thousands mark (a comma, dot, space or apostrophe) is recognised on its own, but only in groups of three digits, or India's 12,34,567. So the wrong choice leaves amounts unreadable rather than wrong: 12.50 read with Comma is not 1250.
• Date format. Empty keeps dates exactly as your export writes them. Type the format instead, like dd/mm/yyyy, mm/dd/yyyy, yyyy-mm-dd or dd-mmm-yyyy for 20-Aug-2020, and they are stored as 2025-12-31, so they sort and filter as dates. If a date only reads in another order (12/31/2025 when you typed dd/mm/yyyy), nothing is imported, and Recued names the line and the format it reads in.

⚠ Set the date format before your first import from a card. The date is part of what makes an expense the same expense, so expenses you imported with their dates as written would come in again as new. The check shows them as new before anything is recorded.