REDA One Help Center
EN
Language
English EN Español ES Português PT Italiano coming soon Français FR Deutsch coming soon العربية coming soon
reda.one ↗
Home / REDA Financials AI / Banking / Bank Statements / Statement Validation

Statement Validation

A reconciliation is only as trustworthy as the statement under it, so REDA Financials guards statements from three directions: arithmetic that must hold, periods that mustn't collide, and edit-locks once reconciliation has relied on the data. Here's the checklist the system runs so you don't have to.

Getting there. Open the App Launcher (the grid icon at the top-left of any page) → REDA Financials AI → the Bank Statements tab, then open a statement to see its Net Movement, tallies and validation state.
Access you'll need. Editing or deleting statements requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view statements but not change them.

The arithmetic layer

CheckWhat it tells you
Net Movement = Closing − Opening BalanceWhat the bank says happened this period
Total Credits / Total Debits / Line CountWhat the imported lines add up to — Net Movement should equal credits minus debits; a gap means missing or duplicated lines
Reconciled Amount / Unreconciled AmountMatching progress: "Unreconciled Amount… Zero means fully reconciled."

First thing after every import: eyeball Net Movement against the lines' total. Catching a truncated CSV here costs seconds; catching it mid-reconciliation costs an evening.

The check, on July's real numbers

Meridian's July statement, straight after import:

FigureValueWhere it comes from
Opening / Closing Balance$875,700.00 / $872,455.00Typed from the bank's statement header
Net Movement−$3,245.00Calculated: 872,455 − 875,700
Line Count4The imported rows
Total Credits$9,000.00The one deposit: Corvus Consulting's rent
Total Debits$12,245.002,200 + 10,000 + 45 — two payments and the bank's fee
Credits − Debits−$3,245.00Equals Net Movement — the file is complete and correctly signed

Ten seconds of arithmetic, and July's statement is proven internally consistent before any matching begins. Had a row gone missing, the two −3,245 figures would disagree by exactly the missing amount — a search term, handed to you.

The gap names the culprit. Credits-minus-debits off from Net Movement by $45? Look for a $45 row (missing or doubled). Off by an even twice some line's amount? That line's sign is flipped. The arithmetic doesn't just detect problems — it describes them.

The structural layer

  • No overlapping periods per bank account — the double-import killer: "An overlapping statement period already exists for this bank account."
  • Date sanity: "Period End must be on or after Period Start." · "Statement Date must fall within the statement period."
  • Signed, non-zero lines with a required date, description, amount and type.
The overlap guard is your only dedupe — respect it. Nothing else stops the same month arriving twice; the calendar is the whole defense. That's why working around it (nudging a re-import's dates) is the one way to genuinely corrupt a statement history: the guard can't protect dates that lie.

The protection layer

  • A reconciled statement's balances lock ("Cannot edit a reconciled statement.") and reconciled lines' amounts/dates lock — the evidence under a signed-off reconciliation can't quietly change.
  • Deletion is progressively barred: active/reconciled statements can't be deleted, and any statement whose lines are matched into a reconciliation refuses deletion until those are unmatched — "Cannot delete this Bank Statement because one or more of its lines are reconciled to a posted transaction."
The balances are load-bearing. Opening and Closing Balance aren't decorative — the closing figure is what you'll type as the reconciliation's Ending Bank Balance, and the zero-difference gate measures against it. Enter them exactly as the bank prints them, to the cent.

Every message, verbatim

The complete set of statement guards, quoted exactly, with the response each one wants:

The messageWhat it means / what to do
"Period End must be on or after Period Start."The period runs backwards — fix the date range.
"Statement Date must fall within the statement period."The statement's own date has strayed outside its period — align the three dates.
"An overlapping statement period already exists for this bank account."Some existing statement already covers part of these dates. Usually a double import — find the original on the account's Bank Statements list.
"Statement line amount cannot be zero."Zero rows explain nothing — leave the bank's informational rows out.
"Cannot edit a reconciled statement."Balances lock once the statement stands under a reconciliation — the evidence a sign-off relied on can't quietly change.
"Cannot edit a reconciled statement line."The line-level version: a matched line's amount and date are what the match asserted. Unmatch first, deliberately.
"Cannot add lines to a reconciled statement."A sealed month doesn't grow new transactions. A genuinely missing line means reopening the reconciliation first.
"Cannot delete an active or reconciled statement."Statements that reconciliation has touched (In Progress or beyond) don't delete — only fresh, untouched imports do.
"Cannot delete this Bank Statement because one or more of its lines are reconciled to a posted transaction. Unmatch those lines or remove the reconciliation first."The deepest guard: even one matched line anchors the whole statement. It cannot be bypassed by any import or tool.
"Cannot delete this Bank Statement Line because it is reconciled to a posted transaction. Unmatch it or remove the reconciliation first."Same protection, one line at a time.

Cross-currency matches within tolerance

One validation used to be absolute: a receipt or payment whose currency differed from the bank statement line was blocked from matching outright. That is too strict when the difference is only rounding. Now, when the bank account is held in the entity's functional (home) currency, REDA compares the document's bank-currency value (Amount × Exchange Rate) against the statement line and allows the match if the gap is within the account's Reconciliation Tolerance.

Beyond that tolerance the currency mismatch is still blocked and flagged for review — a large gap is a real discrepancy (a wrong exchange rate, an unbooked bank fee, the wrong document), not a rounding artifact. The default tolerance is 0, so nothing changes until an Accounting Admin or Controller sets a tolerance on the bank account; see Matching in a foreign currency for the setup.

Common mistakes to avoid

MistakeWhy it hurtsDo this instead
Skipping the Net Movement glance after importA truncated file or flipped sign survives until mid-reconciliation, where it costs an evening instead of secondsMake the ten-second arithmetic check a reflex: Credits − Debits = Net Movement, every import
"Correcting" statement balances to agree with the booksThe statement is the bank's testimony — bent to match the books, the reconciliation can only prove a fictionBalances come from the bank, exactly; disagreements get explained on the books' side
Shifting a statement's period to dodge the overlap guardThe guard is your dedupe — dodged, the same month exists twice and every matching pass sees doubleIf a statement needs re-importing, delete the bad one first (possible while untouched), then import with true dates
Trying to tidy old statements by deleting themAnything reconciliation relied on refuses deletion — and should: it's the audit trail under signed-off monthsLeave history standing. Statements cost nothing to keep and everything to lose

Where to go next

  1. Importing Bank Statements — where the checks first run.
  2. Completing a Reconciliation — where the balances get their moment.
  3. Bank Statement Lines — line-level integrity.

Frequently asked questions

Count first (Line Count vs the bank's row count — a truncated file shows immediately), then signs (a withdrawal imported positive doubles the error), then the balances themselves (typo in Opening/Closing). One of the three, every time.

Reopen the reconciliation, unmatch the affected line, correct it (it unlocks once unmatched and the rec is In Progress), rematch, re-complete. Every step is deliberate — which is exactly what you want for changing reconciled evidence.

All of them — feeds and integrations create statements through the same doorway as your CSV uploads, so the date rules, the overlap guard and the deletion protections hold identically. No delivery channel gets to skip validation.

Yes, while it's untouched — a freshly imported statement with no reconciled lines deletes cleanly, which is exactly the "reimport it properly" path. Once reconciliation has relied on it, deletion is progressively barred until every matched line is unmatched.

Matching progress at statement level: Net Movement minus what's been reconciled so far. Its own help text is the summary — "Zero means fully reconciled." A statement showing zero there has every dollar of its movement explained.

Was this article helpful?