NetSuite 2026.2 Bank Import Error Codes: Migration Checklist

Starting in NetSuite 2026.2, custom and third-party bank import plug-ins must support standardized error reporting. The migration has three parts: account-level errorCode reporting in Financial Institution Connectivity Plug-ins, parser-level reporting through addError in Financial Institution Parser Plug-ins, and import-level error handling in both.

This checklist separates those responsibilities, provides the supplied import-level codes, and defines verification steps. Without the updates, automatic bank imports display author-written custom messages or generic errors instead of the standardized reporting.

Key takeaways

• Review account-specific failure branches in getAccounts and getTransactionData, including mappings that currently produce custom text or internal codes.
• Implement parser-level reporting through addError; updating Connectivity Plug-ins alone does not satisfy this requirement.
• Track import-level handling separately for both plug-in types.
• In 2026.2, a displayed free-text failure reason triggers a warning visible to users with Financial Institution Records permission and Edit access.
• failureReason is being phased out and will be ignored in a future release, not necessarily in 2026.2.

1. Inventory the three migration tracks

Create separate review items for each responsibility. This prevents an account-level field change from being mistaken for a complete migration.

Migration track	Implementation to review	Evidence to collect
Account-level errors	Connectivity Plug-in errorCode mappings	Relevant account failure branches return the corresponding standardized codes.
Parser-level errors	Parser Plug-in addError reporting	Validation failures reach addError with their mapped codes.
Import-level errors	Both plug-in types	Whole-import scenarios produce the appropriate standardized output.

For third-party implementations, identify the plug-in author responsible for each change and the person who will verify the result. Use scenario coverage rather than a single successful error test as the acceptance criterion.

Keep credential maintenance separate from error-reporting changes. API secrets management for banking integration and banking integration API secret management are adjacent reading; changing an error mapping does not resolve the underlying failure condition.

2. Map account-level failures to errorCode

Review account-specific failures in the Financial Institution Connectivity Plug-in, including locked accounts, incorrect credentials, and expired consent. Trace each scenario through any preprocessing that converts external failure information into custom messages or internal codes.

1. Inspect getAccounts. Record each account-specific failure branch, including uncommon banking API responses. Capture the condition selecting the branch, not only its current message.
2. Inspect getTransactionData. Repeat the inventory for account-specific failures encountered while obtaining transaction data. Keep these distinct from failures affecting the import as a whole.
3. Select the corresponding published account-level code. Use the Bank Import Error Codes Reference rather than constructing a value from the code pattern.
4. Supply the mapped value through errorCode. Update intermediate mappings as well as the final reporting branch.
5. Audit remaining failureReason usage. Confirm that every relevant account-level scenario returns errorCode, including edge cases in both methods.

For example, treat expired consent as a mapping review item with an external condition, selected account-level code, reporting location, and observed result. The import-level table below does not supply the account-level code for expired consent; do not reuse a similarly worded import-level code as a substitute.

Use Oracle's account-error implementation guidance for the Connectivity Plug-in update.

3. Adopt addError for parser-level failures

The Financial Institution Parser Plug-in update covers parser-level failures, including validation errors related to transaction processing. Adding errorCode to Connectivity Plug-in output does not replace this work.

1. Inventory validation branches. Identify the input condition and reporting location for each parser-level failure.
2. Map each scenario to its corresponding standardized code. Avoid using one generic code for distinct validation failures when corresponding codes are available.
3. Report through addError. Ensure errors processed from the external source are relayed using standardized codes.
4. Test branches individually. Verify the intended code reaches addError, rather than merely checking that the function is called somewhere.

Use this review template for account and parser mappings. It is an acceptance artifact, not a NetSuite API schema:

Review item	What to record
Failure condition	The external response or validation condition being tested
Scope	Account-level, parser-level, or import-level responsibility
Selected code	The corresponding published standardized value
Reporting location	The implementation branch being changed
Verification	Expected output and observed result

Oracle provides separate parser-error implementation guidance. If your backlog also includes BAI2 parser enhancements, keep those changes independently testable. For this migration, verify standardized error reporting separately from other parser behavior.

4. Add import-level handling to both plug-in types

Both Connectivity and Parser Plug-ins require import-level standardized error handling. Treat this as a separate implementation task, not a consequence of completing account or parser mappings.

Use Oracle's guidance for Parser Plug-in import errors and Connectivity Plug-in import errors. Do not infer an import-level function signature from the account-level errorCode property or parser-level addError requirement.

Prioritize these distinctions during review:

• Connection versus retrieval: 0000000001 identifies a connectivity error; 0000000002 means the connection succeeded but transaction data could not be retrieved.
• Character size versus transaction volume: 0000000003 concerns the supported character limit; 0000000200 concerns the transaction processing limit. Their recommended responses differ.
• All accounts failing versus connection failure: 0000200000 points to unavailable data for the requested accounts. Review account-specific errors when available.
• Configuration versus processing failures: Include inactive plug-ins and invalid Connectivity Plug-in input in scenario coverage, not just connection failures.
• Fallback versus a named scenario: Reserve 0000000000 for an issue that cannot be expressed with an available code.

5. Check the code structure and import-level reference

Codes follow XYYYNNNNZZ. Use the structure as a review check, not a way to invent new values.

• X — scope/type: 0 means file/import-level, 1 means record-level, and 2 means account-level. Record-level errors include transaction and balance errors.
• YYY — data format: 000 means format-agnostic; 010 means CSV using the standard template; 020 means BAI2; 030 means CAMT053, the ISO 20022 Cash Management Bank to Customer Statement message.
• NNNN — numeric identifier: Identifies the specific error.
• ZZ — variant: Identifies context-specific variants or subtypes.

The following import-level codes apply across supported file formats. Preserve leading zeroes in mappings and test expectations.

Error code	Error scenario	Message and recommended action
0000000000	Issue that cannot be expressed with an available error code	Unexpected error. For manual imports, try again. For automatic imports, wait for the next scheduled import or contact support if the issue continues.
0000000001	Connectivity error	The financial institution could not be connected. Administrators should review the Execution Log on the Plug-In Implementation page; other users should contact their administrator.
0000000002	Data retrieval issue	The connection succeeded, but transaction data could not be retrieved. Administrators should review the Execution Log on the Plug-In Implementation page; other users should contact their administrator.
0000000003	Character limit exceeded	The plug-in sent data exceeding the supported character limit. Administrators should contact the plug-in developer to send smaller chunks; other users should contact their administrator.
0000000100	Inactive Bank Statement Parser plug-in	Administrators should reactivate the plug-in or modify the format profile to use an active plug-in. Other users should contact their administrator.
0000000101	Inactive Financial Institution Parser plug-in	Administrators should reactivate the plug-in or modify the format profile to use an active plug-in. Other users should contact their administrator.
0000000102	Inactive Financial Institution Connectivity plug-in	Administrators should reactivate the plug-in or modify the format profile to use an active plug-in. Other users should contact their administrator.
0000000200	Transaction count exceeds the system processing limit	Remaining transactions will be imported at the next scheduled import.
0000000300	Invalid input from the Financial Institution Connectivity plug-in	Administrators should contact the plug-in author to modify the plug-in. Other users should contact their administrator.
0000200000	All accounts fail	The financial institution could not provide data for the requested accounts. Review and resolve account-specific errors, if available; otherwise, contact your administrator.
0000300000	Import took too long and was automatically stopped	For bank connections, wait for the next scheduled import. For file imports, try reimporting.

6. Verify messages, warnings, and support handoffs

Code review alone does not establish what users see. Test the resulting standardized messages and the warning behavior with the relevant permission.

1. Use Financial Institution Records permission with Edit access. In 2026.2, these users can see the warning when a free-text failure reason appears. A test without that access does not establish whether the warning is absent for its intended audience.
2. Check the displayed identifier. Standardized messages include the associated code, such as (Error 0000000001) for a connectivity error. Do not accept descriptive text alone as evidence of standardized output.
3. Retest former failureReason branches. The property is being phased out and will be ignored in a future release. Do not describe it as already ignored in 2026.2.
4. Check operational instructions. For connectivity and retrieval errors, administrators should be directed to the Execution Log on the Plug-In Implementation page; other users should contact their administrator.
5. Close each migration track separately. Record evidence for account-level mappings, parser-level reporting, and import-level handling in both plug-in types.

The practical completion test is a reviewed scenario ledger with observed standardized output—not simply the presence of errorCode or addError in the implementation.

Related reading

• Brazil Banking Integration setup in NetSuite
• Adding the test field to bank statement headers