Electronic bank statement import errors

When an electronic bank statement is rejected—or imports with missing, duplicated, or reversed transactions—the file is only one possible cause. The failure can be in the source statement, the bank’s implementation profile, a conversion or transport step, or the ERP’s format, account, and transaction mappings.

Start with the symptom, preserve the original export, and identify the first layer that changed or rejected the data. Editing the file before that investigation can make reconciliation riskier.

Current CorrectBankFile scope: the live validator supports OFX, QFX, QBO, bounded CAMT.053, and MT940 structural diagnosis. BAI2 remains guidance-only. CorrectBankFile does not diagnose bank-profile rules, transformations, mappings, or ERP configuration.

File rejected before any statement appears

Likely causes include:

• the wrong format or import profile was selected;
• the file is truncated, empty, or actually contains a portal error page;
• XML is not well formed;
• a text format has broken tags, records, delimiters, or line endings;
• the message version or bank profile is unsupported;
• encoding declarations and actual bytes disagree.

Confirm the file family from its content, not only its extension. CAMT.053 should identify its ISO 20022 message family and version in the XML namespace. MT940 should contain its statement tags. BAI2 should have a coherent record hierarchy. OFX-family exports should contain the expected header/body structure.

The account is not recognized

An importer can parse the statement but fail to associate it with one configured bank account. Compare the source account identifiers with the destination’s bank-account master. Depending on the format and system, matching may use account number, IBAN, routing details, bank identifier, SWIFT/BIC, legal entity, or another configured reference.

Do not remove identifiers to make a test file “anonymous” and then use the result to diagnose account matching. Redaction can itself create the failure. Use controlled placeholders in an approved test environment.

Opening or closing balances fail validation

Check:

• statement currency against account currency;
• opening balance against the previous accepted closing balance;
• credit/debit direction and amount signs;
• transaction totals against the balance movement;
• statement dates and overlapping periods;
• expected balance types in the bank and destination profiles.

A structurally readable file can still fail business validation. Microsoft Dynamics 365 Finance, for example, documents validation of bank-account match, currency, consecutive balances, non-overlapping dates, line dates, and the relationship between opening balance, summarized lines, and ending balance.

Transactions are missing

First determine whether the entries are absent from the source or dropped later. Typical causes include:

• a date filter or closed accounting period;
• unmapped transaction codes;
• aggregate/batch entries that the transformation does not expand;
• malformed continuation or remittance data;
• a multi-account file where one account did not map;
• the importer treating entries as already processed.

Compare source entry counts and amounts with the imported statement before changing reconciliation rules.

Transactions are duplicated

Duplicate prevention depends on stable statement and transaction identifiers. A bank migration, converter, or new format can change those identifiers. The same entries may then look new, while repeated identifiers can cause distinct entries to be skipped.

Also check whether the same statement period was imported twice under different filenames or formats. Filename differences do not necessarily make the statement unique.

Debit and credit signs are reversed

Formats represent direction differently. A source may carry a credit/debit indicator, a signed amount, or a transaction code whose mapping supplies direction. A transformation can apply the sign twice, and an ERP can map an unknown code to the wrong transaction type.

Do not bulk-negate amounts. Compare representative fees, payments, deposits, refunds, and transfers with the bank’s visible statement and the destination’s documented mapping.

Dates are rejected or land in the wrong period

Bank statements can contain statement dates, booking dates, value dates, and timestamps. A destination may validate line dates against the statement range or map one date concept into the ledger. Failures appear when dates are malformed, outside the statement period, in a closed period, or transformed using the wrong timezone or date field.

Document which source date drives posting and reconciliation before changing a mapping.

Transaction codes are not mapped

CAMT.053 bank transaction codes, BAI2 type codes, and bank-specific MT940 conventions may drive destination classification. If the source value is valid but absent from the ERP mapping, the correct fix is usually a reviewed configuration update—not rewriting bank data to resemble a different transaction.

Ask whether the bank recently changed its export version, service, or code set. Compare a known-good prior statement from the same bank and account.

The file imports but does not reconcile

This usually points beyond basic parsing. Check balance continuity, sign mappings, duplicate handling, matching references, tolerances, date rules, and whether aggregated bank entries correspond to several ledger transactions.

Reconciliation rules are destination behavior. A file-level diagnostic can expose suspicious data, but it cannot prove that an ERP’s matching or accounting configuration is correct.

Route by statement format

• CAMT.053: use the CAMT.053 error guide and, for a bounded structural pass, the CAMT.053 validator.
• MT940: use the MT940 format and errors guide and run bounded structural diagnosis.
• BAI2: use the BAI2 format and errors guide. CorrectBankFile does not currently accept BAI2 uploads.
• OFX, QFX, or QBO: use bank-file diagnosis for the supported source format.

A controlled troubleshooting workflow

1. Preserve the original file and import log.
2. Identify the exact format, version, bank profile, account, and statement period.
3. Record where the failure occurs: transport, parsing, account association, validation, posting, or reconciliation.
4. Compare with a known-good file from the same bank and destination profile.
5. Verify account, currency, balances, dates, identifiers, and transaction mappings.
6. Check any transformation before modifying the source.
7. Test one change at a time in a non-production environment.
8. Reconcile counts and totals before posting.

If you need help identifying the failure boundary, contact CorrectBankFile with the source format, bank profile, destination, and exact stage. Do not attach an unredacted financial statement to a routine support request.

Related help articles

CAMT.053 bank statement errors Inspect CAMT.053 namespace, statement, balance, entry, date, and mapping problems. MT940 format and import errors Troubleshoot tagged statements, transaction lines, references, and bank variants. BAI2 format and import errors Troubleshoot record hierarchy, continuations, counts, totals, and mappings. Dynamics 365 bank statement imports Separate source problems from Dynamics format and account configuration.

Check your bank file before you import again

Upload the export and get practical diagnostics for finance-file import failures.

Try the file checker Back to Help