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 your export and read the header row. Put those exact column names into the settings below. date, merchant and total are required — they are what tells one charge from another. The rest are optional; leave a box empty and the column is simply not mapped.

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.

Check first

Turn on Check first and 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. 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 will not read

A cell that cannot be parsed is stored EMPTY, never as zero, and the row still lands. The summary counts them and shows the first few with their line numbers. Set the thousands separator your export uses — "1,240.50" reads as nothing without it, and a period that quietly drops its largest charges still looks like a clean import.