Imports

What an import is

An import is a job that reads one file and produces drafts at the end. You hand over the file. The first thing you get back is not rows but a record: it exists before it has produced anything, you can look at it while it is working, and it stays put afterwards.

The record holds the file, the wallet you scoped the import 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 the import 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.

The two kinds of import

There are two kinds of import. They are different jobs, not two settings on one. A statement import takes a CSV or PDF export from your bank. A receipt import takes a photograph: JPEG, PNG, WebP or an iPhone's HEIC.

The file decides which kind you get, not a menu. A .csv or .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, WebP or HEIC, and an iPhone's HEIC is converted to JPEG as it is uploaded; a statement has to be a CSV or a PDF. Anything else is refused, with a message naming what it wanted.

The size limits differ. A CSV is accepted up to 5 MB, a PDF or a receipt image up to 10 MB. Those limits are measured as the file uploads, 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 an import 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 moves no wallet balance. Nothing an import produces is yours until you publish it, and the guide to reviewing AI drafts covers that step.

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 between an import and its rows 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.

The receipt's own text

A receipt photograph carries more than the total that reaches the transaction: the merchant, every line, the tax brackets, what was paid and how. SavingStat keeps that reading as the file's transcript, and you can open it on the transaction the photo is attached to.

The transcript belongs to the file rather than to the import. A receipt you attached by hand, to a row that came off a statement or to a transaction you typed yourself, can be read out the same way with Generate on the attachment. No import is created and no draft appears. Only the transcript.

A transcript is generated on request, not automatically. Generating takes a few moments, and the transcript appears on its own when it is ready. If the image cannot be read, the reason is shown next to a Retry, and a transcript you already had is left as it was instead of lost to the attempt.

JPEG, PNG and WebP can be read, and HEIC photos are converted to JPEG at upload. Only the file's owner sees a transcript: someone you share a budget with sees the attached photograph, never your reading of it. The guide to reading a receipt walks through the whole of it.

The lifecycle of an import

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 import 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 drafts and puts the same file back in the queue, keeping anything you had already published.