Imports

What an import is

An import is a job. You hand over a file, and what you get back first is not rows but a record: something that exists before it has produced anything, that you can look at while it is working, and that stays put afterwards.

The record holds the file, the wallet you scoped it to, and how far it has got. If it went wrong, it holds the reason as well. None of the reading happens while you wait. The upload is accepted and queued, the work is done elsewhere, and the record is updated as that work reports back.

Because the import outlives the upload, so does provenance. Everything it creates points back at it, and the file itself is attached to each of those rows, so a transaction from last spring can still show you the statement it was read out of.

Two kinds

There are two, and they are different jobs rather than two settings on one. A statement import takes a CSV or a PDF export from your bank. A receipt import takes a photograph: JPEG, PNG or WebP.

Which one you get is decided by the file rather than by a menu: a .csv or a .pdf is sent as a statement, anything else as a receipt. What is then accepted is narrower than that. A receipt has to be a JPEG, PNG or WebP; a statement has to be a CSV or a PDF. Anything else is refused, with a message naming what it wanted.

The sizes they accept differ. A CSV is taken up to 5 MB; a PDF or a receipt image up to 10 MB. Those limits are measured as the file goes up, and only then: a file you pick out of your library instead is not measured again.

The paths differ afterwards too. A statement is read in chunks, reports how many rows of the total it has got through, and hands back drafts while it is still going. A receipt produces a single draft and has no row count to report.

What it produces

Drafts, not transactions. A draft has everything a transaction has: an amount, a date, a wallet, a comment, and a category, budget or income source chosen for it. But it is held apart from your data. It stays out of your transaction list and it moves no wallet balance. Nothing an import produces is yours until you publish it, which is what Review AI drafts is about.

The file is kept too. It goes into your library and is attached to every transaction the import creates, and the two kinds arrive differently: a receipt scan is attached as shared, a statement file as private.

The link is durable rather than incidental. Deleting an import asks separately about the drafts still waiting and about the rows you have already published, and whatever you keep is released from the import rather than going with it.

Its lifecycle

An import is pending first, then processing, and ends as either completed or failed. That is the whole of it. There is no paused state and no half-finished one to sit in.

While a statement import is processing it reports how many rows of the total it has read, and the figure updates itself. A job still pending some minutes after you started it has been accepted but not picked up yet: the file was fine, the work has not begun.

A completed import can still carry a note about something it could not do, shown above the rows. A failed one carries the reason instead, in plain language with the underlying message behind a toggle, and its page shows that error and the file rather than any rows. Drafts an interrupted run had already produced are not listed there. Retrying clears those and puts the same file back in the queue, keeping anything you had already published.