Importing a statement

Upload a statement and it is fingerprinted, parsed, categorized and balance-chain verified before anything is written to your ledger. What you see on the preview screen is what will be committed — nothing lands until you say so.

The balance chain

Every row's running balance must follow from the one before it. If the chain holds from your stated opening balance to your stated closing balance, the file was read correctly and nothing was dropped or double-counted. This is the single strongest check in the product, and it is arithmetic rather than judgement.

Why a commit can be blocked

If the statement does not print an opening balance, we can DERIVE one from row one. That derivation is self-consistent — the chain will still say "verified" — so a wrong guess about row one's direction cannot be detected by the chain at all.

That is why a batch with a derived opening is un-committable until a human types the opening off the statement. Correcting it re-parses the file rather than patching the staged rows, because the deduplication hash covers the amount and the category is chosen from the sign.

Beta formats

Some bank formats are marked beta: the layout has been implemented but not yet verified against a real sample. Beta imports work and carry a lower confidence cap. If one misreads your statement, that is the most useful bug report this product can receive.

Deleting and restoring

Deleting an import hard-deletes its transactions — that is what frees the duplicate-detection hashes so you can re-import a corrected file. The staged rows survive for 30 days, which is what lets Restore work without the original file.