Citibank Statement to Excel Converter

With debits and credits in separate columns, a running balance to follow, and fee and interest lines mixed in, re-keying a Citi statement into Excel is slow and easy to get wrong — and one misplaced amount breaks the reconciliation.

FlowParse reads the whole statement at once, signs every amount, and validates the balance, turning the job into a 30-second conversion.

Citibank presents transactions with date, description, separate debit and credit amounts and a running balance, with fee and interest detail held apart from the main sequence. Structurally that puts it between the two common patterns: it has the per-row balance that block-grouped statements lack, and the split amount columns that single-column statements avoid.

The split columns are where care is needed. Direction is expressed by which of the two columns a figure occupies rather than by a sign, and on most rows one of them is empty. Merge them during extraction and direction disappears while every amount survives — the failure that leaves a file looking entirely reasonable and a reconciliation out by exactly twice the affected total.

The running balance is the compensation, and it is worth using. Each row's balance minus the previous row's should equal that row's signed amount, which pins a misread figure to a specific row rather than leaving you to search the statement. FlowParse merges the debit and credit columns into one signed amount, keeps the fee and interest detail out of the transaction sequence, and runs that chain alongside the document-level check.

Layouts differ across the checking tiers — Access, Regular, Citigold — and savings, and the card portfolio uses a charges-and-payments format with its own arithmetic entirely. Fields are located by meaning rather than by position, so a tier change does not require reconfiguration.

Four things, all of them consequences of the split-column layout and the separated fee detail.

Debit and credit columns merged. The most consequential, because it destroys direction while leaving the numbers intact. Payments read as receipts, and the arithmetic misses by twice their value.

The running balance imported as an amount. It is a position, not a movement. Included as a transaction it inflates the file by the size of the balance — usually obvious, which makes it one of the more forgiving errors here.

Fee and interest detail double-counted. Because Citi holds this apart from the main transaction sequence, it can be read twice: once from its own block and once where it also appears in the sequence. The result is a statement that will not reconcile, with a difference equal to the duplicated fees.

Card statements checked against a bank identity. A Citi card statement runs from a previous balance to a new balance and inverts the sign convention relative to a checking account. Checked as though it were a bank statement it reconciles against nothing, and the failure looks like an extraction problem when it is a document-type problem.

For a year end, a loan application or a catch-up, two checks matter and they answer different questions.

Within each statement: the opening balance plus every transaction should equal the printed closing balance. That proves the document is whole — nothing dropped at a page break, no summary line imported as a transaction.

Between statements: each closing balance should equal the next statement's opening balance, exactly, right through the year. That proves the series is unbroken. A statement can be internally perfect while a month is missing entirely from the folder, and the gap is invisible from either side of it because every surviving document balances on its own terms.

Keep checking and card accounts as separate series when you run this. They are separate balance chains and joining them produces a comparison that means nothing.

One practical note on Citi specifically: statement availability and the process for retrieving older or archived statements vary by product and change over time, and their public statements page is rendered behind a sign-in. Rather than repeat a figure we cannot verify from Citi's own published page, check the current retention window in your own online banking — and, as with any bank, download what you need while the account is open, since closing it removes the self-service route entirely.

Citi holds fee and interest detail apart from the main transaction sequence, and that separation is genuinely helpful for a reader and a specific trap for a converter.

The trap is double counting. A fee can appear in its own detail block and also within the transaction sequence, and a reader that treats every table on the page as a source of transactions picks it up twice. The result is a statement that will not reconcile, with a difference equal exactly to the duplicated fees — which is at least a diagnosable failure, since the gap points straight at the fee total.

The opposite error is quieter and worse. Where a fee exists only in the detail block and is skipped because the block was ignored, the transaction list is short by that amount, the document-level check fails, and nothing about the transaction sequence looks wrong. The gap is real and the cause is somewhere the reader was not looking.

Handling it correctly means deciding, per statement, whether a given fee is represented once or twice on the page, and reconciling to the printed closing balance to prove the decision was right. That is precisely what the document's own arithmetic is for: it is the only thing that can adjudicate between two plausible readings of the same page.

Layout varies across the checking tiers as well — Access, Regular and Citigold differ in presentation and in which detail blocks appear — and the card portfolio is a different document again, with a previous-balance-to-new-balance identity and an inverted sign convention. Fields are located by meaning rather than by fixed position, which is what allows one approach to cover the tiers without per-account configuration, and the appropriate check is chosen from the document type rather than applied uniformly.

One consequence worth planning for: if a Citi account is upgraded or downgraded between tiers mid-year, the statements either side of that change can look materially different while describing the same continuous account. That is not a gap and should not be treated as one — the balance chain runs straight through it, and the continuity test confirms as much, because the closing balance before the change still equals the opening balance after it.

That is a good illustration of why balances make a better completeness test than appearances do. A layout change, a new column, a redesigned header — none of them touch the arithmetic. Two statements that look nothing alike still have to meet at the same number, and if they do, the series is intact regardless of how the pages were formatted.