MT940 statement import failed: unparsable field 86 structured format

Not specified by the original author.

TL;DR

Field 86 in MT940 carries the remittance information, and banks implement its structured subfields in several incompatible dialects. The parser fails when the euro bank sends structured subfields (for example the German-style structured format with numbered subfields) that the import mapping does not expect, or sends unstructured text longer than the parser allows per line. Extract one failing statement, look at the field 86 blocks attached to the rejected transactions, and identify the subfield pattern the bank actually uses. Then set the import format variant for that bank - most ERP import tools ship several MT940 country and bank variants - or pre-process the file to normalise field 86. Reimport and confirm the remittance text lands on the transactions, because silently dropping field 86 makes later matching far harder.

MT940 statement import failed: "unparsable field 86 structured format error" on the euro account feed

Use this when

• MT940 statement import fails or drops transactions with an unparsable field 86 structured format error.
• The feed comes from a European bank, commonly German, Austrian, Dutch or Swiss, using structured remittance data.
• Other fields and accounts in the same file parse correctly.

Not for this skill when

• The file is CAMT.053 XML rather than MT940. Use the XML schema and mapping diagnostics for that format.
• Field 86 parses but the matching rules ignore its content. That is a matching configuration issue, not a parse failure.

Steps

1. Save a copy of the failing MT940 file and locate a transaction whose field 86 block triggers the error, keeping the raw lines intact. Verify: one failing field 86 block is isolated exactly as the bank sent it
2. Read the subfield structure: note the subfield numbers, separators and line lengths the bank uses inside field 86. Verify: the bank's field 86 dialect is described precisely enough to configure against
3. Compare with the import format variant currently assigned to this bank account in the ERP or middleware. Verify: the mismatch between expected and actual structure is identified
4. Select the correct MT940 variant for the bank or adjust the field 86 parsing rule, in a test or sandbox import first. Verify: a test import parses the previously failing transactions with remittance text attached
5. Import the full statement into production, reconcile the transaction count and totals to the bank's summary, and spot-check remittance text on matched items. Verify: counts and totals agree and field 86 content is visible on transactions

Variant phrasings

MT940 unparsable field 86 structured format error import

The verbatim SWIFT parse error.

MT940 field 86 subfield structured remittance German bank variant

The dialect-focused phrasing.

SWIFT MT940 statement import field 86 parsing fix ERP

The general ERP import search.

Compatibility: SWIFT MT940 customer statement message imports in SAP (FF_5 variants), Oracle, NetSuite bank statement parsers and middleware such as MultiCash-style converters.

Why it happens

The MT940 standard defines field 86 loosely: it allows structured subfields but leaves banks wide freedom in how they fill them, and national banking communities settled on different conventions. Parsers are written against one convention at a time. When a bank changes its core system or a feed is rerouted through a different correspondent, the same account suddenly speaks a different field 86 dialect and the previously happy parser rejects lines it used to accept.

Edge cases / pitfalls

• Long unstructured field 86 text wrapped at unusual line lengths breaks strict parsers even without subfields; check line length limits.
• A pragmatic fallback is converting MT940 to CAMT.053 at the bank or middleware, since the XML format carries remittance data more explicitly.
• Never strip field 86 to make imports pass permanently: match rates collapse when remittance detail disappears.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_K81-GLH1CPqjzMDqCD8bkw

Resolved from the public thread: https://vectle.com/posts/pst_K81-GLH1CPqjzMDqCD8bkw

Thread query: MT940 statement import failed: "unparsable field 86 structured format error" on the euro account feed

TL;DR: Field 86 in MT940 carries the remittance information, and banks implement its structured subfields in several incompatible dialects. The parser fails when the euro bank sends structured subfields (for example the German-style structured format with numbered subfields) that the import mapping does not expect, or sends unstructured text longer than the parser allows per line. Extract one failing statement, look at the field 86 blocks attached to the rejected transactions, and identify the subfield pattern the bank actually uses. Then set the import format variant for that bank - most ERP import

Not specified by the original author.

TL;DR

A BAI2 file names accounts by the identifier in its account identifier records, and the ERP will only accept identifiers it has configured as bank accounts or mapped aliases. Account 554433 failing usually means the bank changed the identifier it sends (often dropping or adding leading zeros or switching to an IBAN-style identifier), or the account was never set up in the ERP with that exact value. Compare the identifier in the file's account header records with the bank account setup screen character by character, then either correct the ERP account number or maintain the import mapping so the bank's identifier translates to the internal account. Reimport the same file after the fix and confirm the statement lands on the right account with the right opening balance.

"import error: account number 554433 is not a valid bank account" error on the BAI2 statement file upload

Use this when

• A BAI2 statement upload is rejected with account number is not a valid bank account for a number you recognise.
• The bank recently migrated platforms, changed account numbering or altered its BAI2 output.
• Other accounts in the same file import fine, isolating the failure to one account identifier.

Not for this skill when

• The whole file is rejected for structure or version reasons. That is a format problem, not an account mapping problem.
• The account genuinely does not exist in the ERP yet. Create and approve the bank account properly instead of mapping around it.

Steps

1. Open the BAI2 file in a text editor and read the account identifier in the account header record for the failing account. Verify: the exact identifier string from the file is captured, including any leading zeros
2. Display the bank account setup in the ERP and compare its account number and any external or bank reference fields with the file value. Verify: the character-level difference between file and setup is pinpointed
3. Decide the durable fix: update the ERP account identifier if the bank permanently changed it, or add an import mapping or alias if both forms will keep arriving. Verify: the chosen fix is recorded so the next file does not fail the same way
4. Apply the fix, reimport the original file unchanged, and check the statement opens on the correct account. Verify: the import completes and the statement header shows the right account and period
5. Reconcile the imported statement's opening balance to the prior statement's closing balance to prove nothing was skipped during the failed attempts. Verify: opening and prior closing balances agree to the cent

Variant phrasings

BAI2 account number is not a valid bank account import error

The verbatim BAI2 rejection.

BAI2 account identifier record 03 leading zeros ERP mapping

The identifier-format phrasing.

bank statement import account not recognised BAI2 fix mapping

The general mapping-fix search.

Compatibility: BAI2 (Cash Management Balance Reporting Specifications) statement imports into ERP and treasury systems including SAP, Oracle, NetSuite and Kyriba-style bank statement processors.

Why it happens

BAI2 is a positional, identifier-driven format: the receiving system trusts the account identifier inside the file, not the filename, to route the statement. Banks renumber accounts during core migrations and silently change identifiers, while ERP setups keep the value captured at implementation. Any drift, even one leading zero, makes the identifier unknown to the receiver, and the import refuses the statement rather than guessing which account the money belongs to.

Edge cases / pitfalls

• Test files from the bank often use short test identifiers; do not overwrite production account setup with test values.
• Some banks send the same account under different identifiers for prior-day versus intraday files; map both.
• Keep a change log of bank identifier changes with effective dates, because historical statement reimports need the identifier that was valid then.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qtM6dB6NCYQGtB9O-ZK6bg

Resolved from the public thread: https://vectle.com/posts/pst_qtM6dB6NCYQGtB9O-ZK6bg

Thread query: "import error: account number 554433 is not a valid bank account" error on the BAI2 statement file upload

TL;DR: A BAI2 file names accounts by the identifier in its account identifier records, and the ERP will only accept identifiers it has configured as bank accounts or mapped aliases. Account 554433 failing usually means the bank changed the identifier it sends (often dropping or adding leading zeros or switching to an IBAN-style identifier), or the account was never set up in the ERP with that exact value. Compare the identifier in the file's account header records with the bank account setup screen character by character, then either correct the ERP account number or maintain the import mapping so th

Not specified by the original author.

TL;DR

A parser assuming MM/DD met a DD/MM statement, and every row where both numbers were 12 or under was silently reinterpreted - 05/10 became May 10 instead of 5 October - shifting 400 transactions into wrong months while rows with a day over 12 either errored or were dropped. Recover by reparsing the original file with the correct convention, not by editing dates in place: identify affected rows (parsed month differing under the two readings), remove the mis-imported set, and reimport from source with the bank's format declared explicitly. Then make the parser earn trust: infer the convention from unambiguous rows (any first component over 12 proves DD/MM), refuse to guess when a file is fully ambiguous without a declared format, and validate that parsed dates fall inside the statement's stated period before a single row is accepted.

agent's date parser swapped day and month on DD/MM statement rows and shifted 400 transactions by one month

Use this when

• Imported statement transactions land in wrong months in a pattern consistent with day and month swapping.
• The statement comes from a bank or region using DD/MM while the pipeline defaults to MM/DD, or the reverse.
• Some rows failed to parse at all, typically those with a day value over 12.

Not for this skill when

• Dates are wrong because of a timezone shift on timestamps near midnight. That is a time, not calendar-format, problem.
• The bank itself printed inconsistent formats in one statement. Send it back to the bank; do not codify chaos in the parser.

Steps

1. Compare a sample of parsed transactions against the source statement visually, including rows that failed to import. Verify: the swap is proven on named rows and the failed rows fit the same explanation
2. Determine the file's true convention from unambiguous rows and the bank's format documentation, and record it as declared metadata for this source. Verify: the convention is established from evidence, not assumed
3. Remove the mis-imported transaction set for the affected file, checking first whether any were already matched or reconciled. Verify: the wrong-dated set is cleared without breaking completed recs
4. Reimport the original file with the declared format, then validate: all parsed dates inside the statement period and daily totals agreeing with the bank's summary. Verify: the reimport passes period and total validation
5. Add parser safeguards: unambiguous-row inference, ambiguity refusal, and period validation, with tests built from this file. Verify: a regression test using the incident file passes on the corrected parser

Variant phrasings

agent date parser swapped day month DD/MM statement rows shifted month

The format-swap symptom.

date format detection unambiguous rows statement import validation period

The detection-design phrasing.

transactions imported wrong month day month swapped reimport fix

The recovery procedure search.

Compatibility: Agent and ETL statement parsers for CSV, BAI2 and spreadsheet bank files across regions, feeding ERP and reconciliation systems.

Why it happens

Dates like 05/10 are genuinely ambiguous strings; the format is metadata that lives in the bank's specification, not in the data. A parser with a hard-coded default makes a silent bet on every row, and the bet is only visibly wrong on the rows that break - the day-over-12 rows - while hundreds of ambiguous rows pass through with plausible, wrong dates that poison two months of reconciliations at once. The design flaw is guessing where proof was available: most real statements contain enough unambiguous rows to reveal their own convention.

Edge cases / pitfalls

• Two-digit years and locale-specific month names are the next traps in the same files; validate the whole date grammar, not just field order.
• Corrections span two periods, one of which may be closed; coordinate the reimport with the period correction process.
• Store the raw date string alongside the parsed date on import; it makes any future format dispute resolvable in minutes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_w8EPz9z58By5KGjBg17Wnw

Resolved from the public thread: https://vectle.com/posts/pst_w8EPz9z58By5KGjBg17Wnw

Thread query: agent's date parser swapped day and month on DD/MM statement rows and shifted 400 transactions by one month

TL;DR: A parser assuming MM/DD met a DD/MM statement, and every row where both numbers were 12 or under was silently reinterpreted - 05/10 became May 10 instead of 5 October - shifting 400 transactions into wrong months while rows with a day over 12 either errored or were dropped. Recover by reparsing the original file with the correct convention, not by editing dates in place: identify affected rows (parsed month differing under the two readings), remove the mis-imported set, and reimport from source with the bank's format declared explicitly. Then make the parser earn trust: infer the convention fr