Updating Parser Plug-ins for Parser Error Codes

This procedure provides a generic approach for updating your Financial Institution Parser Plug-in to use standardized parser er ror codes by leveraging the addError interface function. Implement this update to ensure parser-level error reporting in NetSuite is standardized and actionable.

Note:

Standardized error codes will be adopted by the Bank Feeds SuiteApp in a phased rollout, beginning with Yodlee in the upgrade targeted for March 11, 2026. Support for MX and Salt Edge is planned for a subsequent release in April 2026. Until these upgrades, only custom or third-party plug-ins that have been updated as described in this topic will surface standardized error codes.

To update your parser plug-in to use standardized error codes for parser-level errors:

Identify all validation or parser-level failure scenarios.

Review your plug-in's transaction validation and data processing logic. Find every place where a failure or validation error is surfaced at the parser or transaction level, such as invalid amounts, invalid dates, missing fields, or incorrect record structure.
Map each failure scenario to a standardized parser error code.

For each parser-level failure you identify, map it to the corresponding standardized error code listed in Bank Import Error Codes (Reference). Double-check all branches of your validation logic, including rarely encountered or edge case data problems, to ensure that every parser error scenario is mapped to a standardized error code.

Update your code to use the addError interface function.

If your plug-in already preprocesses failure information from the external source, update that mapping logic to use standardized error codes. Then, supply the code using the addError function. For example, your plug-in might preprocess external errors by mapping them to your own custom error messages or internal codes.

Note:

The following code samples are examples and should be adapted to your plug-in implementation.

Legacy approach (before standardization):

Parser or validation errors are typically handled with custom logic, such as returning strings, logging, or collecting errors in arrays. For example:

                functionvalidateTransaction(transaction) {
    if (isNaN(Number(transaction.amount))) {
        return"Invalid amount format";
    }
    // Additional validation logic...returnnull;
}

// orlet errors = [];
if (isNaN(Number(transaction.amount))) {
    errors.push("Invalid amount on line 1");
}

Standardized approach (required for standardized error codes):

Parser and validation errors are reported using the addError interface function. For usage details and an example, see addError(options).

                functionvalidateTransaction(context, transaction) {
    let valid = true;
    if (isNaN(Number(transaction.amount))) {
        context.addError({
            errorCode: '1000000300',  // Standard error code for incorrect number formatlineNumber: 1,
            characterOffset: 2
        });
        valid = false;
    }
    // Additional validation as required.return valid;
}

parseData: function (context) {
    try {
        const rawData = JSON.parse(context.inputData.getContents());
        rawData.accounts.forEach(function (account) {
            try {
                const accountData = context.createAccountData({
                    accountId: account.accountId,
                    dataAsOfDate: account.asOf,
                    closingBalance: account.balance,
                });
                account.transactions.forEach(function (transaction) {
                    if (validateTransaction(context, transaction)) {
                        accountData.createNewTransaction(transaction);
                    }
                });
            } catch (e) {
                throw e; // Caught exceptions may be used to create parser errors as needed.
            }
        });
        returntrue;
    } catch (e) {
        throw error.create({
            name: 'BANK_IMPORT_STANDARD_ERROR',
            message: '0000000000'// Use the code that matches the specific failure scenario
        });
    }
}

You should use the addError interface function to report each parser or validation error, specifying the standardized errorCode as well as any available error context, such as lineNumber and characterOffset. Continue this pattern for all parser-level failures throughout your plug-in logic. For more information about these input parameters, see errorCode, lineNumber, and characterOffset.

Additional Guidance

For more guidance, do the following:

Test your plug-in by simulating various data and validation errors and confirm that the UI displays the expected standardized error codes and messages. For more information, see Testing a Financial Institution Parser Plug-in.
For details about updating parser plug-ins for import-level errors, see Updating Parser Plug-ins for Import Error Codes.
For information about updating connectivity plug-ins for import-level errors, see Updating Connectivity Plug-ins for Import Error Codes.
For details about receiving account-level errors, see Updating Connectivity Plug-ins for Account Error Codes.

For more information about parser error codes or mapping scenarios, see Bank Import Error Codes (Reference). If you need assistance, contact NetSuite Support.

To update your parser plug-in to use standardized error codes for parser-level errors:

Additional Guidance

Related Topics