Start free
bankingConcept

Statement Import

A statement import is the act of bringing an entire bank or card statement's transactions into BalanceMCP in a single call, verified against the statement's own beginning and ending balance.

In short

The one-time act that gets bank activity into the books at all. A whole statement goes in as one call — never split across several, since deduplication depends partly on position within the batch — and the beginning balance plus every transaction has to equal the stated ending balance, or the import comes back flagged.

Also called: importing a statement

A statement import is the mechanism that gets a bank's real activity into BalanceMCP in the first place. A statement — a PDF, a CSV, even pasted text — is extracted and its transactions imported together, in one call, as one complete statement, along with the beginning and ending balance the statement itself states.

That "one call" detail is not a suggestion: deduplication uses a content hash combined with each transaction's position within the batch it arrived in. A group of genuinely identical, same-day charges split across two separate import calls can be misread as duplicates and silently dropped, even though they were real, distinct transactions. Importing the entire statement at once avoids this entirely.

The arithmetic check is the safety net built into every import: the stated beginning balance plus every transaction's amount has to equal the stated ending balance. When it doesn't, the import is flagged rather than silently accepted — a signal that the extraction likely missed a row or picked up an extra one, worth checking against the source document before trusting the numbers downstream.

Re-importing a statement that's already been brought in is completely safe: the same content hash that catches genuine duplicates recognizes rows already stored and inserts nothing new. There's also no live bank feed behind any of this — every import is a specific, manual extraction from a statement someone (or an AI assistant) already has.

What people get wrong

  • Splitting one statement across multiple import calls — deduplication depends partly on position within a single batch, so this can misread real repeats as duplicates.
  • Ignoring a flagged import instead of re-checking the source document for a row that spans a page break or was picked up twice.
  • Hesitating to re-import a statement out of fear of duplicating it — a re-import safely inserts nothing new for rows already stored.

Common questions

Can I import a statement in several smaller batches?
It's best not to — deduplication depends partly on where a transaction falls within a single import call, so splitting a statement can make real repeated charges near the split point look like duplicates and get dropped.
Is it safe to import the same statement twice by accident?
Yes — a re-import recognizes transactions already stored and inserts nothing new for them.

Machine-readable: /api/knowledge/concept:statement-import