Which of the ten balance types is your cash position reading?

Two numbers for the same account, on the same morning.

Someone in finance opens the bank portal, looks at the cash figure in the ledger, and the two do not agree. This happens in companies with one bank account and in companies with forty, and it happens on days when nothing has gone wrong.

Search the question and the answers are consistent and sensible. Outstanding cheques that have not cleared. Deposits in transit. Fees and interest the bank booked before anyone keyed them. Posting errors. Unauthorised activity. Every one of those is a real cause and worth working through, and the explanations are usually accompanied by a reconciliation formula that adds the deposits in transit and subtracts the outstanding payments.

There is a step before all of that, and it rarely gets mentioned. The formula assumes the bank statement has a balance, singular. It does not. So we downloaded the ISO 20022 external code sets, the actual published package rather than a description of it, and counted what a statement is allowed to tell you.

Ten balance types, and twenty two ways to qualify them.

The balance types a bank statement can carry are not invented per bank. They come from a published list, and the current one is the ISO 20022 external code sets, 2Q2026 publication. We parsed the JSON package directly. It holds 163 code sets in total, and three of them decide what a cash position can know.

ExternalBalanceType1Code carries exactly ten codes: CLAV, CLBD, FWAV, INFO, ITAV, ITBD, OPAV, OPBD, PRCD and XPCD. ExternalBalanceSubType1Code carries twenty two more, which qualify a balance rather than replace it, among them blocked funds, unblocked funds, amounts set aside and intermediate page totals. ExternalEntryStatus1Code carries four, and we will come back to those because they matter as much as the balances do.

The consequence is simple to state and easy to miss. One account, on one day, can be reported several times over, with every figure correct and every figure answering a different question. A difference between two of them is not an error to investigate. It is information, and in the case of the gap between booked and available money it is often the most operationally useful number on the statement.

Three of them do the work.

The closing booked balance is the one a reconciliation needs, and the reason is in its definition rather than in convention. The code set defines it as the opening booked balance plus every entry booked to the account during the reporting period. That makes it the only balance you can recompute from the lines you were sent, which makes it the only one you can prove. Every other balance is a statement of fact by the bank that you can record but cannot derive.

The closing available balance answers a different question: what can we pay today. The code set defines it as money at the disposal of the account owner on the date specified, and a portal usually leads with it because it is the figure a person wants. Holds, uncleared deposits and an overdraft line all sit in the gap between the two. One bank guide adds a detail worth knowing, which is that the same field means the balance subject to interest charges when the account is overdrawn.

The expected balance is the one most teams do not know they are being offered. The code set defines it as booked entries plus pending items known at the time of calculation, projecting the end of day balance if everything books and nothing else is posted. That is a same day cash forecast produced by the party with the best possible view of the inputs, and it costs nothing to store. It is also the right thing to measure your own forecast against.

There is an asymmetry in how these are stamped that is easy to lose on the way in. Reading Bank of America’s camt.053 reference guide directly, the booked balance examples carry a plain date, while the closing available balance example carries a time to the second, and the guide notes the available figure is shown once on the last page with the date the funds are made available. A cash position stored against a date cannot distinguish two intraday figures for the same account, which is exactly the situation where somebody asks why the number changed.

That guide is also a useful reality check on how many of the ten you will actually see. It maps four of them from the older MT940 fields, the opening booked balance from field 60F or 60M, the closing booked balance from 62F or 62M, the closing available balance from field 64 and the forward available balance from field 65. It then removes the forward available balance in this bank’s CBPR+ implementation, which leaves three. The closing available balance is marked optional, so even that is not guaranteed.

The balance that is only a page marker.

Among the twenty two sub type codes there is one called INTM, defined in the code set as an intermediate amount such as an opening or closing balance carried forward from one page to the next in a multi page statement or report. On its own that sounds like housekeeping. The bank guide turns it into something worth checking.

The rule it states is this: where the page number is one, the opening booked balance is provided without the INTM sub type, and where the page number is greater than one, the opening booked balance is provided with it. The closing balance follows the same pattern keyed on the last page indicator. So a four page statement contains four balances that all carry the balance type for opening booked, and exactly one of them is the opening balance of the period. The other three are page carry forwards.

A reader that selects on the balance type and ignores the sub type will find several candidates and take one. It will not fail, it will not log anything, and the number it returns will be a real balance from a real statement, which is what makes this worth looking for rather than waiting for.

The part that makes it a current risk rather than an old one is where the field came from. In the bank guide’s own field table, the sub type element is marked as an additional field introduced with camt. MT940 had no equivalent, because MT940 handled the same problem with separate tags, field 60F for the first opening balance and 60M for an intermediate one, and 62F and 62M on the closing side. A parser written for MT940 knew the difference from the tag. The same parser pointed at camt.053 has nowhere to put the qualifier and no reason to ask for it.

Four statuses, and only one of them means the money moved.

The same exercise on the entry side is shorter and the payoff is larger. ExternalEntryStatus1Code has four codes, and their definitions in the code set are precise about what each one licenses you to do.

Two details in those definitions are doing real work. The code set notes that booked is the only status that can be reversed, which means a reversal arriving later against a booked entry is ordinary and your model should expect it. It also notes that pending cannot be reversed, which means a pending entry leaves by becoming booked rather than by being cancelled. A system that posts pending entries to the ledger to make things tie sooner is therefore waiting for a reversal that the standard does not provide.

The common handling is to filter on import and keep only the booked lines, which keeps the ledger clean and throws away the forecast. Future entries in particular are a dated commitment the bank is already holding, which is better information about next week than anything you could infer from your own records.

Then there are the two dates. The guide’s field table marks value date as mandatory on a statement line and entry date as optional, in both the older format and the newer one, and defines them as the date the debit or credit is effective and the date the transaction is booked to the account. Most ledgers key on the booking date. That is the field the message allows to be missing. Neither choice is wrong, and a choice nobody wrote down becomes an argument at the first period boundary where the two dates straddle a cut off.

Two controls the standard gives away.

Reading definitions this closely has a direct payoff, because two of them are not descriptions at all. They are assertions of equality, which means they can be implemented as checks without anybody having to agree a policy first.

The first is in the definition of the opening booked balance, which states that it always equals the closing book balance from the previous report. Run that daily per account and a break tells you something specific happened: a statement is missing, a file was imported twice, or a period was restated. The older format asserts the same thing in different words, since the bank guide notes that the MT940 opening balance field carries the same value as the closing balance field of the previous statement message for that account.

The second is the previously closed balance, whose definition says the opening booked balance for the new period has to equal it. Where a bank sends it, it is a second independent anchor, which is useful precisely when the first check is ambiguous because a statement has not arrived yet.

The third check is not given to you but falls out of the definition: recompute the closing booked balance as the opening balance plus the sum of the booked entries, and compare it to the figure the bank reported. A break means a line is missing, a line is counted twice, or something not booked was treated as booked. None of the three needs a new system, and all three are the kind of check that is cheap to add before a close and expensive to need halfway through one.

The field most statement tables are missing.

All of the above lands on a small piece of schema, and it is worth being concrete about it using our own, since the gap is easier to describe honestly than hypothetically. In Rivane, a bank statement header holds the account, the statement date, an opening balance, a closing balance, the currency, the source file and format, and who imported it when. Each statement line holds a line date, an optional value date, the amount, the description, a reference, a counterparty, the running balance and a stable external identifier, with a uniqueness constraint on that identifier so a redelivered file cannot double count.

That is a reasonable statement table and it has the same gap most of them have. There are two balance columns and no balance type beside them. A message carrying a booked balance, an available balance and a projection collapses into two numbers, and which two it keeps is decided by the importer rather than recorded in the row. Nothing downstream can tell whether the closing balance it is reading is booked or available, so nothing downstream can tell whether a difference is an exception or a definition.

Three smaller gaps sit alongside it. The statement date is a date, so an available balance timed to the second arrives and loses its time. There is no entry status on the line, so booked, pending, future and informational entries would be indistinguishable once imported. And the line date is required while the value date is nullable, which is the reverse of the message, where the value date is the mandatory field. We are describing our own schema here because it is the one we can describe accurately, and because a field that is missing is a clearer thing to point at than a field that is present.

Those gaps are visible in a place most people would not look for them: the defaults of the matching engine. Our bank reconciliation matcher allows a five day window between the statement line date and the journal entry date, and an amount tolerance of zero, applied symmetrically, with a tolerance above zero reserved for named and bounded bank fee differences whose residual posts a real adjustment entry rather than being absorbed silently. The zero is a deliberate position: amounts should agree. The five days are something else. They are the slack a matcher needs when it cannot be sure whether the date on each side means the same thing. Knowing which date you hold is what lets that window close, and a narrower window is a stronger match.

Matches carry their provenance for the same reason. A match records whether a person, a rule or a model made it, along with a confidence label and the reason, and a model’s confidence does not override the window or the tolerance. A claimed high confidence cannot push a match through a guard it fails. That ordering matters more as more of this work gets suggested automatically, because the guard is the part that is checkable afterwards.

# A statement header that can say which number it is and when it was true.
# Shape only. No real bank, account or entity.

bank_statement:
  account:        ACCT-0001
  currency:       USD
  source_format:  camt.053.001.08      # version recorded, not assumed
  source_file:    sha256:9f2c...        # raw bytes kept for re-reading
  page:           3 of 4                # so a gap is distinguishable
  balances:                             # a row each, not two columns
    - type: OPBD
      sub_type: INTM                     # page carry forward, NOT the real open
      amount: 1402233.18
      indicator: CRDT
      as_of: 2026-10-02
    - type: CLBD
      sub_type: null                     # the figure the ledger reconciles to
      amount: 1388104.52
      indicator: CRDT
      as_of: 2026-10-02
    - type: CLAV
      sub_type: null                     # what can actually be paid
      amount: 1301884.52
      indicator: CRDT
      as_of: 2026-10-02T17:00:04         # timed, not dated
    - type: XPCD
      sub_type: null                     # the bank's own end of day projection
      amount: 1377219.09
      indicator: CRDT
      as_of: 2026-10-02T17:00:04

bank_statement_line:
  value_date:   2026-10-02               # mandatory in the message
  booking_date: 2026-10-02               # optional in the message
  posted_on:    value_date               # which one the ledger used, recorded
  status:       BOOK                      # BOOK, PDNG, FUTR or INFO
  amount:       -48219.40
  references:
    account_servicer: ABKREF-125646
    end_to_end:       E2E-0004821
    uetr:             7a562c67-ca16-48ba-b074-65581be6f001

# The rules that make the above hold:
#   a balance qualified INTM is a page marker and is never read as a period balance
#   OPBD of this report equals CLBD of the previous report, checked daily
#   CLBD equals OPBD plus the sum of entries with status BOOK, recomputed
#   only status BOOK posts to the ledger; PDNG and FUTR feed the forecast
#   a position carries the timestamp of the balance it was built from

Nobody is going to make you upgrade, which is the opening.

It would be reasonable to assume all of this is forced on a schedule, since the move to ISO 20022 has had plenty of deadlines attached to it. For corporate statements, it is not. Reading Citi’s ISO 20022 migration FAQ directly, updated 16 February 2026, the requirement for payments and statements to migrate from MT to MX sits in the interbank space, clients can continue to receive statements in the format of their choice, and no end date has been announced for the coexistence of MT statements and advices.

That cuts both ways, and the second way is the useful one. There is no cliff to prepare for, and equally there is no cutover that will hand you the better data by itself. The same FAQ lists what the newer reporting adds: end to end identifiers, the unique transaction reference, structured party details including address and account identification, and structured remittance information, while noting that the older non XML formats stay more restricted because they carry fewer native data elements.

Those references are exactly what an automatic matcher keys on. A matcher has amount, date and reference to work with, and of the three the reference is the only one that identifies rather than merely narrows. Richer references mean a tighter date window and fewer matches that rest on plausibility. So the practical move is a question to each bank about which version it can send for your accounts, which is a request you can make this week, rather than a project waiting on a mandate that is not coming.

Two operational details from the same document are worth carrying into whatever you build. A bank can offer more than one version at the same time, so the version belongs on the statement row rather than in a developer’s memory. And whether one file holds one account or several depends on the channel, since the CBPR+ version over FINplus reports one account per message while the same bank’s file channel versions can report more than one. If the file import mechanics are the part you are working on, the BAI2 and MT940 statement import page covers the control totals, hashing and duplicate handling that sit underneath all of this.

An implementation checklist.

• Ask each bank which balance types it sends you today, on which message and which version. This is a short email and it is the whole foundation of the rest. Most teams have never asked, and the answer differs by bank and sometimes by account.
• Open one real statement file and list the balances in it. Not the portal screen, the file. Note the type code, the sub type code if there is one, the date or time on each, and whether the available balance is present at all, since one bank’s guide marks the closing available field optional.
• Decide which single balance the ledger reconciles to, and write it down as a decision rather than leaving it in the importer. For a period reconciliation that is the closing booked balance, because it is the only one defined as the sum of the entries you were given.
• Decide separately which balance answers what can we pay today. That is the available balance, and keeping the two questions apart is most of the confusion gone, because the two figures are allowed to differ and neither is wrong.
• Check the sub type on every balance you read, and skip the ones qualified as intermediate. On a multi page statement the opening and closing balances are repeated per page with that qualifier, and a reader that ignores it will take a page marker for the real figure.
• Implement the two equalities the standard gives you as a daily check: this report’s opening booked balance against the previous report’s closing booked balance, and against the previously closed balance where it is sent. Both are asserted by the code set, so you are not inventing a control.
• Recompute the closing booked balance from the opening balance and the booked entries, and compare it to the balance the bank reported. A break means a missing entry, a double counted one, or a pending item posted as booked, and the sign tells you which direction to look.
• Store the entry status on the line rather than filtering on import. Pending and future entries are good forecasting data, and discarding them to keep the ledger clean throws away the one dated view of near term cash the bank is willing to give you.
• Record which date you are keying on and keep both. Value date is the date the movement is effective and the format makes it mandatory, while the booking date is optional, which is the reverse of how most ledgers treat them.
• Stamp the position with the moment it was true, not the day. An interim balance is explicitly provisional, and an available balance can arrive with a time to the second, so a position labelled only with a date cannot say which of two intraday figures it holds.
• Ask your bank what the newer reporting version would add for your accounts. End to end identifiers, the unique transaction reference and structured remittance data are the fields a matcher keys on, and the richer version is a request rather than a mandate.

Where this usually goes wrong.

• Comparing the ledger to whichever balance the portal shows first. Portals usually lead with the available balance because it is the one a human wants, while the ledger can only agree with the booked balance. The reconciliation then opens with a difference that is not an error, and the real exceptions get investigated last.
• Reading the balance type and ignoring the sub type. The qualifier is what separates a real opening balance from a page break artefact in a multi page statement, and it is also what marks blocked funds as untouchable. Ignoring it is the single most likely way to import a confidently wrong number.
• Carrying an MT940 reader forward unchanged. The sub type element is an additional field introduced with camt, so a parser modelled on the older format has no slot for it. The import keeps working, which is exactly why the gap can sit there for a long time.
• Treating pending entries as booked so the ledger ties sooner. Pending means the booking is not complete, and an entry posted early has to be unwound if it never books. The code set is explicit that pending cannot be reversed, so there is no reversal coming to tidy it up.
• Assuming one statement file means one account. Whether a file reports one account or several depends on the channel: the CBPR+ version over FINplus reports one account per message, while the same bank’s file channel versions can report more than one. An importer that assumes either will eventually be handed the other.
• Assuming the version is fixed. A bank can offer more than one camt.053 version at once, and the fields available differ between them. Code written against the version you receive today, with no record of which version it was, is hard to debug the week after a bank upgrades you.
• Waiting for a deadline that is not coming for corporate statements. The migration requirement sits in the interbank space, and one bank states plainly that no end date has been announced for the coexistence of MT statements. Waiting for a cutover means waiting for the richer data instead of asking for it.
• Keying the ledger to the booking date without recording that choice. The booking date is the optional one in both formats, so it can be absent, and posting from it moves entries across a period boundary differently than posting from the value date would. Either choice is defensible once it is written down.
• Letting a wide date window stand in for knowing which date you hold. A generous window raises the match rate and lowers the meaning of a match, because it lets a matcher reach past the right entry to a plausible wrong one. Narrowing it is only safe once the date on each side is known.

Data and API considerations.

• Model the statement balance as its own row with a type, an optional sub type, a credit or debit indicator, an amount, a currency and a timestamp. One opening and one closing column on the statement header cannot hold a message that reports several balances, and it quietly forces the importer to choose which two to keep.
• Keep the timestamp at the precision the message gives you. A booked balance arrives dated to the day and an available balance can arrive timed to the second, so a date column loses the only field that distinguishes two intraday figures for the same account.
• Put the entry status on the statement line next to the amount. Four statuses are defined, only one of them means money has moved, and a line without a status cannot tell a posting rule from a forecasting row.
• Keep both dates on the line and mark which one the posting used. Value date is mandatory in the message and booking date is optional, so a schema that requires the booking date and allows the value date to be null has the standard’s guarantee exactly backwards.
• Keep the bank references as first class fields rather than inside the description text: the account servicer reference, the end to end identifier and the unique transaction reference where the message carries them. These are what a matcher keys on, and parsing them back out of free text later is lossy.
• Record the source format and version on the statement header, and the raw file alongside it. A balance that looks wrong is usually a reading problem rather than a bank problem, and the only way to settle that is to re-read the original bytes.
• Make the import idempotent on a stable identifier per line, so a redelivered file cannot double count. A duplicate entry breaks the closing balance recomputation in the same direction as a genuinely missing one, which makes the two hard to tell apart without the guard.
• Store the statement sequence and page information. The equalities between one report’s opening balance and the previous report’s closing balance only work if you can tell a missing statement from a statement that has not arrived yet.

What the audit evidence looks like.

• For each period and account: the closing booked balance as reported by the bank, the same figure recomputed from the opening balance and the booked entries, and the difference, which should be zero.
• The unbroken chain of opening and closing booked balances across consecutive statements, which is the positive evidence that no statement is missing and none was imported twice.
• The balance type and sub type actually read for each figure the ledger reconciled to, so a reviewer can see that a booked balance was compared with a booked balance.
• The pending and future entries held at period end, with the dates they were expected to book, separated from the booked population rather than mixed into it.
• The source file, its format and version, and the import timestamp and user, retained so any disputed figure can be re-read from the original rather than argued from the parsed row.
• For each match: the two dates, the amount difference, the reference relied on, and whether a person or the engine made it, so a reviewer can see what the match was based on rather than only that it happened.

Questions worth asking internally.

• Which balance type does our cash position read today, and did anybody choose it, or did the importer choose it for us?
• If the bank portal and our ledger disagree this morning, can we tell within a minute whether we are looking at a booked figure against an available one?
• Does our statement reader check the balance sub type, and what does it do with a balance qualified as intermediate on page three of a statement?
• Can we show, for the last twelve months, that each statement’s opening booked balance equalled the previous statement’s closing booked balance?
• Do we keep pending and future entries, and if not, where does our view of next week’s cash come from instead?
• Which date does a bank line post on in our ledger, and is that the date the message guarantees or the one it marks optional?
• Which camt version does each of our banks send us, and do we know what the next version up would add for our accounts?

A cash position that can say which number it is.

The encouraging part of this is how much of it is already written down. The balance types are published and counted. Their definitions are precise enough that two of them assert equalities you can turn into daily checks without a policy debate. The page carry forward qualifier that makes a multi page statement ambiguous is documented in the banks’ own specifications. None of this requires a project, a vendor or a mandate. It requires reading one real statement file and deciding, deliberately, which balance means what.

The work that follows pays for itself past the original question. A statement header that records each balance with its type and the moment it was true can answer why the number changed. A line that keeps its entry status gives you a near term cash view that came from the bank rather than from a guess. Both dates on the line, with a note of which one posted, lets a matching window narrow, and a narrower window means more matches that are right for a reason. If it helps to see how statement import, matching and the evidence behind each match fit together, the Rivane reconciliation page walks through it.

Sources

• ISO 20022, External Code Sets, 2Q2026 publication. The JSON package was downloaded from iso20022.org and parsed directly rather than summarised, and every code count in this article comes from its own entries. Source for ExternalBalanceType1Code carrying ten codes, for ExternalBalanceSubType1Code carrying twenty two, for ExternalEntryStatus1Code carrying four, and for the official definition of each code quoted or described below, including the statement that an opening booked balance always equals the closing book balance from the previous report.
• Bank of America, SWIFT reference guide, Bank to Customer Statement (camt.053). The PDF was downloaded and read directly. Source for the mapping of MT940 fields 60F and 60M, 62F and 62M, 64 and 65 onto the balance types OPBD, CLBD, CLAV and FWAV, for the page number and last page rules that attach the INTM sub type, for the sub type element being an additional field introduced with camt, for value date being mandatory on a statement line while entry date is optional, for the available balance example carrying a time rather than a date, and for the forward available balance being removed in this bank’s CBPR+ implementation.
• Citi, ISO 20022 Migration FAQs, last updated 16 February 2026. The PDF was downloaded and read directly. Source for the statement that the requirement for payments and statements to migrate from MT to MX is only in the interbank space and that clients can continue to receive statements in the format of their choice, for no end date having been announced for the coexistence of MT statements and advices, for this bank offering both camt.053.001.02 and camt.053.001.08, for the CBPR+ version over FINplus reporting one account per message while the file channel versions can report several, and for the enhanced data that the newer reporting carries.
• ISO 20022, message definitions for bank to customer cash management, which cover camt.052 account report, camt.053 account statement and camt.054 debit and credit notification. Read for the division of labour between the intraday report, the end of period statement and the event driven notification, and for the balance element sitting at statement level while entry status sits on each entry.
• J.P. Morgan, ISO 20022 migration guidance. Read for a second bank’s description of the same coexistence position, that corporate reporting formats move on each bank’s own schedule rather than on a single industry cutover date.
• Rivane reconciliation. The bank statement, statement line and match tables described in this article are the ones built and shipped, along with the matching guard defaults quoted: a five day window between the statement line date and the journal entry date, and an amount tolerance of zero. The limits described are also what is in the schema today, including the statement header holding one opening and one closing balance with no balance type beside them.

A note on how this was researched. The ISO 20022 external code set package was downloaded and parsed rather than summarised, and the counts of ten balance types, twenty two balance sub types and four entry statuses are from its own entries in the 2Q2026 publication. Those counts are ours; the definitions quoted or described are the published ones. The two bank specifications were downloaded as PDFs and read directly in the files rather than through a summary, which is how the page number and last page rules for the intermediate sub type, the mandatory and optional marking of the two dates, and the date against time distinction between the booked and available balances were established. Code lists change by publication, so the quarter is named rather than left implied, and anything built on an earlier package is worth re-checking against the current one. No bank, account, entity or customer in this article is real, and the figures in the example statement are placeholders chosen to illustrate the shape.

On embedded social posts: we looked for public posts from banks, standards bodies or treasury practitioners discussing statement balance types and found none we could verify as current, relevant and authentic, so this article uses ordinary citations instead of embeds.