Skip to main content
Use this page when a transaction file is rejected, partially rejected, or you are not sure what went wrong. Find your issue below and follow the steps to resolve it.

Before you troubleshoot

Before you troubleshoot a specific error, run through these checks:
  • Confirm the filename follows the correct naming convention for your file format (I-file, V-file, or XML I-file).
  • Verify the file sequence number has not already been used.
  • Check that all merchant IDs in the file match IDs that were boarded with Fexco.
  • Confirm the file’s summary totals reconcile with the transaction records (financial integrity).
  • Confirm that record sequence numbers start at 0000001 and increment by one with no gaps (logical integrity).

File rejection issues

The .status file shows status S3 and includes an XML parse error with a line number and column number.Common causes
  • Unclosed tags, incorrect element names, or invalid attribute values.
  • Encoding mismatches.
  • The disposition attribute contains an invalid value (must be either production or test).
How to fix
  1. Read the parse error in the .status file. Use the line and column numbers to locate the error in your XML file.
  2. Validate the XML file against Fexco’s XSD schema before resubmitting.
  3. Resubmit with the same sequence number (do not increment for a fully rejected file).
The .status file shows status S4.Why this happensA file with the same sequence number has already been uploaded and accepted.How to fixCheck your submission history and increment the sequence number to the next unused value. Resubmit with the new sequence number.
The confirmation text file shows the file is rejected with code R10, R11, or R12.Common causes
  • The file totals do not reconcile (financial integrity): a summary, claim, or trailer total does not match the transactions it covers.
  • The record sequence numbers are not consecutive (logical integrity): a gap, duplicate, or incorrect total count in the UTL.
How to fix
  1. Check financial integrity. Verify the hierarchical totals at every level: each E4/E5 summary must total its transactions, each E7/E8 claim must total its summaries, and the UTL must total all claims.
  2. Check logical integrity. Verify that sequence numbers start at 0000001 and increment by one with no gaps. The record count in the UTL must equal the highest sequence number.
  3. Resubmit with the same sequence number. Update the filename date if resubmitting on a different day.
The confirmation text file shows a rejection code between R01 and R04.Common causes
  • The filename does not follow the naming convention (IXXXYYYYMMDDnnnnnn.DAT or VXXXYYYYMMDDnnnnnn.DAT).
  • The submitter identifier does not match the value assigned by Fexco.
  • The date portion is not a valid YYYYMMDD date.
  • The sequence number does not follow the expected sequence.
How to fix
  1. Verify the filename matches the convention described in the I-file guide or V-file guide.
  2. Confirm the three-character submitter identifier matches the value Fexco provided during onboarding.
  3. Resubmit with the same sequence number.
The confirmation text file shows rejection code R05.Why this happensA file with this filename (including sequence number) was already submitted and accepted.How to fixIncrement the sequence number and resubmit.

Transaction rejection issues

The file was accepted, but some transactions failed. The confirmation data file includes rejection codes on the affected transactions.What you are seeing
  • XML I-file: the .status file shows S2. The _rejections.xml file lists the rejected transactions with rejectionReason codes.
  • I-file or V-file: the confirmation text file shows “partially rejected.” The confirmation data file includes a two-digit rejection code on each affected transaction line.
How to fix
  1. Look up the rejection code in the rejection codes reference in Developer resources.
  2. Fix only the rejected transactions. Do not modify transactions that were processed successfully.
  3. Build a new file containing only the corrected transactions. Increment the sequence number by one (because the original file was partially accepted).
  4. Submit the corrected file and verify the new confirmation shows all transactions accepted.
Do not resubmit transactions that were already processed successfully. Including them in the resubmission file causes duplicates.
One or more transactions are rejected with code 03.Common causes
  • The merchant ID does not match a boarded merchant.
  • Short and long merchant IDs are mixed in the same file.
How to fix
  1. Verify the merchant ID matches a boarded merchant.
  2. Confirm all merchant IDs in the file use the same format: either all 11 characters or fewer, or all 12-16 characters.
  3. Resubmit only the corrected transactions.
Transactions are rejected with code 12 or 17.Common causes
  • The exchange rate field is empty, contains non-numeric characters, or is not 13 characters.
  • The base amount, exchange rate, and currency amount are not mathematically consistent.
How to fix
  1. Verify the exchange rate is a 13-character decimal, right-justified, zero-filled (for example, 0000001.06164).
  2. For non-DCC transactions, use 00000001.0000.
  3. Verify that the base amount multiplied by the exchange rate equals the currency amount (within rounding tolerance).

Formatting issues

Transactions are rejected with various codes, or the entire file is rejected with R13 or R14.Why this happensThe I-file and V-file use fixed-length records. Every field must start at the exact character position specified. A single misaligned field shifts all subsequent fields.How to fixOpen the file in a code editor with column view (such as UltraEdit or GNU Emacs) and verify each field starts at the correct position. See the I-file guide or V-file guide for field positions.
Transactions are rejected with code 34 (invalid base amount) or 53 (invalid currency amount).Why this happensAmounts must be in unsigned minor units with no decimal point.How to fixRemove the decimal point and express the amount in the currency’s smallest unit. For example, USD 124.78 becomes 00000012478. See the currency precision table for the correct number of decimal places per currency.
Transactions in JPY, KRW, CLP, or similar currencies are rejected with code 34 or 53.Why this happensCurrencies with zero minor units must be right-padded with 00. This is a specific exception in the formatting rules.How to fixRight-pad the amount with 00. For example, JPY 241,832 becomes 00024183200.
Summary or claim records are rejected with code 22 or 23.Why this happensThe summary or claim code does not match the net direction of the transactions it covers.How to fix
  • Use E4 when sales equal or exceed refunds. Use E5 when refunds exceed sales.
  • Use E8 when sale summaries equal or exceed refund summaries. Use E7 when refund summaries exceed sale summaries.

Resubmission and sequence numbers

After fixing the errors, resubmit the corrected file. The sequence number action depends on the rejection type:
  • Accepted: increment the sequence number by one for the next file.
  • Partially rejected: the file was processed and valid transactions were accepted. Increment the sequence number. Resubmit only the corrected rejected transactions in the next file.
  • Fully rejected: do not increment. Fix the errors and resubmit with the same sequence number. Update the filename date if resubmitting on a different day.

Still having issues?

If you have worked through the steps above and the issue persists, contact Fexco DCC Support with:
  • Your submitter identifier (three-character code).
  • The file format you are using (XML I-file, I-file, or V-file).
  • The filename and sequence number of the rejected file.
  • The full rejection code from the confirmation file.
  • The environment (production or test).
Contact Fexco DCC Support at DCCSupport@fexco.com.

Next steps