> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fexco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# V-file

> Field reference for the V-file (Multi-Merchant Submission File): transaction segments, subrecords, summary records, and rejection codes.

> [!WARNING]
>
> The V-file is a legacy format and is not offered to new customers. For new integrations, use the [XML I-file](https://docs.fexco.com/dcc/developer-resources/file-formats/xml-i-file.md) instead.

This page is the complete field reference for the V-file, the
Multi-Merchant Submission File used by acquirers and payment service
providers (PSPs) to report Dynamic Currency Conversion (DCC) and
domestic transactions to Fexco. Use it alongside the
[Build and submit a V-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/v-file.md)
guide, which covers file construction, encryption, and submission.

> [!NOTE]
>
> All field positions are 1-indexed and fixed-width. Each field must
> start at exactly the position shown. Use zero-fill or space-fill to
> pad unused fields as specified for each field.

## Data type conventions

The following abbreviations describe field encoding and justification
in the V-file format.

| Type | Meaning |
| :- | :- |
| `R` | Right-justify. For numeric fields, pad with leading zeros. For alpha or alphanumeric fields, pad with leading spaces or zeros as specified. |
| `L` | Left-justify. Applies to alpha and alphanumeric fields only. Pad with trailing spaces or zeros as specified. |
| `N` | Numeric (digits 0–9 only). |
| `A` | Alphabetic characters only. |
| `AN` | Alphanumeric. Accepts digits 0–9, uppercase A–Z, and lowercase a–z. |
| `BH` | Binary and hexadecimal. Convert 8-bit binary data to printable hexadecimal. All letters must be uppercase. Left-justify with space fill. |
| `AB` | Binary. Applies to contactless subrecord fields. Fill unused positions with low values (null bytes). |
| Space fill | Fill the specified positions with blank spaces (`0x20`). |
| Zero fill | Fill the specified positions with zeros (`0x30`). |

## Transaction record types

The V-file supports seven transaction record types. The transaction
code is a two-character value where the first character identifies the
terminal environment and the second identifies the transaction direction.
The following table describes each type and the segments it includes.

| Code | Description | Segments included | Record length |
| :- | :- | :- | :- |
| `J1` | POS DCC sale | Segment 1 + Segment 2 Type 1 | 173 |
| `J2` | POS DCC refund | Segment 1 + Segment 2 Type 1 | 173 |
| `J3` | Cash advance (domestic) | Segment 1 + Segment 2 Type 1 | 173 |
| `P1` | ICC DCC POS sale | Segment 1 + Segment 2 Type 1 + Segment 4 | 429 |
| `P2` | ICC DCC POS refund | Segment 1 + Segment 2 Type 1 + Segment 4 | 429 |
| `K1` | Airline DCC sale | Segment 1 + Segment 2 Type 1 + Segment 2 Type 4 + Segment 3 Type 5 | 463 |
| `K2` | Airline DCC refund | Segment 1 + Segment 2 Type 1 + Segment 2 Type 4 + Segment 3 Type 5 | 463 |

## Segment 1 (positions 1–90)

Segment 1 is present in all transaction record types. It occupies
positions 1 through 90 of the transaction line and contains card,
merchant, and terminal information. The following table describes each
field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 19 | N RZ | Card number | Card number as defined by the card scheme. Right-justify, zero-fill. |
| 20 | 2 | AN | Transaction code | Two-character code identifying the record type. The first character is `J`, `K`, or `P`; the second is `1` (sale), `2` (refund), or `3` (cash advance). See [Transaction record types](#transaction-record-types). |
| 22 | 11 | AN R | Terminal ID | Terminal identifier as defined by the acquirer. Right-justify, space-fill. |
| 33 | 4 | N | Card expiry date | Card expiry date in `MMYY` format. For continuous-authority transactions, set to `1234`. |
| 37 | 11 | N RZ | Base amount | Transaction amount in the merchant's pricing currency. Express in unsigned minor units as defined by ISO 4217. No decimal point. Right-justify, zero-fill. For zero-decimal currencies (for example, JPY, CLP), right-pad with `00`. For example, JPY 241832 is `00024183200`; USD 124.78 is `00000012478`. |
| 48 | 6 | AN | Transaction date | Date the transaction occurred. Format: `bYYDDD` where `b` is a mandatory blank space, `YY` is the two-digit year, and `DDD` is the Julian day of the year. For example, 27 September 2010 is ` 10270`. |
| 54 | 6 | N R | Transaction time | Time the transaction occurred in `HHMMSS` format using a 24-hour clock. Zero-fill if not used. |
| 60 | 8 | ASCII 32–126 | Authorisation code | Authorisation code from the card scheme. Accepts ASCII values 32 (space) through 126 (tilde). Zero-fill for NatWest merchants; space-fill for all others when not used. |
| 68 | 12 | AN | Transaction reference | 12-character reference allocated by the merchant. Space-fill if not used. |
| 80 | 1 | N | Switch card issue | First digit of a two-digit issue number, or `0` if the issue number is a single digit. Zero-fill if not used. |
| 81 | 1 | AN | Terminal type | ATM/POS terminal capability. One of: `0` = unspecified; `1` = ICC reader only; `2` = magnetic stripe only; `3` = ICC and magnetic stripe; `4` = no card reader; `A` = contactless-only device. |
| 82 | 1 | N | Switch card issue number | Second digit of a two-digit issue number, or the only digit if the issue number is a single digit. Zero-fill if not used. |
| 83 | 1 | AN | Customer instructions | Card entry and cardholder verification method. A value must be provided; blank spaces are not permitted. See [Customer instructions values](#customer-instructions-values). |
| 84 | 7 | N R | Sequence number | Position of this record within the file. Right-justify, zero-fill. |

### Customer instructions values

The following table lists the allowed values for the Customer instructions
field. Values marked as not supported cause rejection code `11`.

| Value | Description |
| :- | :- |
| `0` | Signed voucher |
| `1` | Mail/telephone order |
| `2` | Continuous authority |
| `3` | PIN verified online |
| `4` | PIN verified offline |
| `5` | Signed voucher, magnetic stripe captured |
| `6` | Signed voucher, keyed at point of sale |
| `7` | Unattended device without PIN verification |
| `8` | PIN verified card transaction, recovered after sale |
| `D` | Downgraded ICC card (Track 2 data only) |
| `F` | ICC card fallback to magnetic stripe |
| `G` | eCommerce: secure transaction with cardholder certificate |
| `H` | eCommerce: non-authenticated security transaction with card acceptor certificate |
| `J` | eCommerce: non-authenticated security transaction without card acceptor certificate using channel encryption (for example, SSL) |
| `L` | eCommerce: non-authenticated security transaction with card acceptor certificate using channel encryption |
| `M` | IC Contactless: full proximity EMV transaction. Segment 4 must be present for all IC contactless full-proximity transactions. |
| `N` | Contactless transaction with Track 2 magstripe data, no cardholder verification |
| `P` | Unattended contactless transaction with Track 2 magstripe data, no cardholder verification |
| `T` | Contactless transaction with Track 2 magstripe data and Consumer Device Cardholder Verification Method (CDCVM) |
| `U` | Unattended contactless transaction with Track 2 magstripe data and CDCVM |
| `V` | Contactless transaction with Track 2 magstripe data and signature |
| `W` | Contactless transaction with Track 2 magstripe data and online PIN |
| `Y` | Token-initiated eCommerce transaction |

## Segment 2 Type 1 (positions 91–173)

Segment 2 Type 1 follows Segment 1 for all transaction record types.
It occupies positions 91 through 173 of the transaction line and
contains currency conversion details. The following table describes
each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 91 | 17 | AN | Statement narrative | Free-text narrative. Useful for reporting and fault-finding. Space-fill if not used. |
| 108 | 8 | AN | Merchant currency identifier | For WorldPay/Streamline merchants only. Space-fill if not used by other acquirers. |
| 116 | 13 | AN | Exchange rate | Exchange rate applied at point of sale. Must include a decimal point. Right-justify, zero-fill to 13 characters. For base currency transactions and cash advances (J3), use `00000001.0000`. For example, a rate of 10.49241 is `000010.49241`. |
| 129 | 1 | N | Method of authorisation | One of: `0` = by terminal; `1` = online to acquirer; `2` = voice to acquirer; `5` = unknown. |
| 130 | 1 | N | Type of purchase transaction | One of: `0` = purchase or refund; `1` = purchase with cashback. |
| 131 | 7 | N | Cash amount | Base amount of a cashback transaction in unsigned minor units. Zero-fill if not a cashback transaction. |
| 138 | 11 | N RZ | Currency amount | Transaction amount in the cardholder's currency. Express in unsigned minor units as defined by ISO 4217. No decimal point. Right-justify, zero-fill. For zero-decimal currencies, right-pad with `00`. For non-DCC and J3 transactions, this value is identical to the base amount. |
| 149 | 2 | N | POS DCC informational code | Zero-fill. |
| 151 | 1 | AN | Total number of subrecords | Number of companion subrecords for this transaction. Set to `0` if no subrecords accompany the transaction. Space-fill or zero-fill if not used. |
| 152 | 8 | AN | EPOS identifier 1 | Alphanumeric identifier for a device within the merchant's Electronic Point of Sale (EPOS) system. Used for per-till reporting. Space-fill if not used. |
| 160 | 4 | N R | Transaction currency code | ISO 4217 four-digit numeric currency code. For example, `0978` for EUR, `0840` for USD. |
| 164 | 4 | N | EPOS transaction number | Four-digit transaction sequence number. Zero-fill if not used. |
| 168 | 4 | N | EPOS identifier 2 | Numeric device identifier for the merchant's EPOS system. Used for per-till reporting. Zero-fill if not used. |
| 172 | 2 | AN | Additional data identifier | Zero-fill if not used. Set to `F1` when an airline itinerary data record follows (K1/K2 transactions). |

## Segment 2 Type 4 (positions 174–256)

Segment 2 Type 4 is required for K1 and K2 (airline) transactions
only. It follows Segment 2 Type 1 on the same line and occupies
positions 174 through 256. It contains airline passenger and booking
data. The following table describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 174 | 14 | AN L | Ticket number | Airline ticket number. Left-justify, space-fill. |
| 188 | 19 | AN | Reserved | Space-fill. |
| 207 | 8 | AN L | Travel agency code | Code identifying the travel agency. Left-justify, space-fill. |
| 215 | 25 | AN L | Ticket agency name | Name of the travel agency. Left-justify, space-fill. |
| 240 | 11 | AN | Reserved | Space-fill. |
| 251 | 4 | N | Number of legs | Number of trip legs in the itinerary. One of: `1`, `2`, `3`, or `4`. |
| 255 | 2 | N | Format type | Airline format type indicator. For example, `45`. |

> [!NOTE]
>
> The `Additional data identifier` field in Segment 2 Type 1 must be
> set to `F1` when Segment 2 Type 4 and Segment 3 Type 5 follow.

## Segment 3 Type 5 (positions 257–463)

Segment 3 Type 5 is required for K1 and K2 (airline) transactions
only. It follows Segment 2 Type 4 on the same line and occupies
positions 257 through 463. It contains passenger name, customer
reference, and itinerary leg data. The following table describes each
field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 257 | 26 | AN L | Passenger name | Name of the passenger. Left-justify, space-fill. |
| 283 | 12 | AN | Customer reference number | Customer booking or reference number. Space-fill if not used. |
| 295 | 13 | AN | Reserved | Zero-fill. |
| 308 | 16 | AN | Reserved | Space-fill. |
| 324 | 3 | AN | Departure airport (leg 1) | International Air Transport Association (IATA) departure airport code for trip leg 1. |
| 327 | 2 | AN | Carrier code (leg 1) | IATA airline carrier code for trip leg 1. |
| 329 | 6 | AN | Fare basis code (leg 1) | Fare basis code for trip leg 1. Space-fill if not used. |
| 335 | 1 | AN | Class of travel (leg 1) | Cabin class for trip leg 1. For example, `Y` for Economy. |
| 336 | 1 | AN | Stop over code (leg 1) | Stop-over indicator for trip leg 1. Space-fill if not used. |
| 337 | 3 | AN | Destination code (leg 1) | IATA destination airport code for trip leg 1. |
| 340 | 6 | N | Date of travel (leg 1) | Departure date for trip leg 1 in `DDMMYY` format. |
| 346 | 12 | N | Reserved (leg 1) | Zero-fill. |
| 358 | 34 | AN | Trip leg 2 | Same field layout as trip leg 1 (departure airport through reserved). Zero-fill or space-fill if the trip has fewer than two legs. |
| 392 | 34 | AN | Trip leg 3 | Same field layout as trip leg 1. Zero-fill or space-fill if the trip has fewer than three legs. |
| 426 | 34 | AN | Trip leg 4 | Same field layout as trip leg 1. Zero-fill or space-fill if the trip has fewer than four legs. |
| 460 | 4 | AN | Reserved | Space-fill. |

## Segment 4 (positions 174–429)

Segment 4 is required for P1 and P2 Integrated Chip Card (ICC)
transactions only. It follows Segment 2 Type 1 and occupies positions
174 through 429 of the transaction line. It contains EMV (Europay,
Mastercard, Visa) cryptogram and terminal data. The following table
describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 174 | 2 | AN | Application PAN sequence number | Application Primary Account Number (PAN) sequence number or issue number. |
| 176 | 2 | AN | Authorisation response code | Response code from the card issuer, or generated by the terminal for offline transactions. |
| 178 | 11 | N | Cryptogram transaction amount | Authorised amount used to generate the cryptogram, excluding adjustments. For contactless transactions, this is the base currency amount captured when the card was tapped. |
| 189 | 2 | N | Cryptogram transaction type | Transaction type passed from the terminal to the card for cryptogram generation. Value `14` is not permitted. |
| 191 | 6 | N | Terminal transaction date | Date used in cryptogram generation in `YYMMDD` format. Must be a valid date; do not zero-fill or space-fill. |
| 197 | 3 | N | Cryptogram transaction currency code | ISO 4217 three-digit numeric currency code of the cryptogram transaction. |
| 200 | 3 | N | Terminal country code | ISO 3166-1 numeric country code of the terminal. |
| 203 | 16 | BH | Transaction cryptogram | Transaction Certificate (TC) or Application Authentication Cryptogram (AAC). |
| 219 | 4 | BH | Application Interchange Profile (AIP) | Indicates the card application capabilities. Corresponds to EMV tag 82. |
| 223 | 4 | BH | Application Transaction Counter (ATC) | Counter maintained by the card application. Corresponds to EMV tag 9F36. |
| 227 | 8 | BH | Unpredictable number | Provides variability for cryptogram generation. |
| 235 | 10 | BH | Terminal Verification Result (TVR) | Status of terminal verification functions. Corresponds to EMV tag 95. |
| 245 | 64 | BH | Issuer Application Data (IAD) | Proprietary application data for the issuer. Corresponds to EMV tag 9F10. |
| 309 | 4 | BH | Application Usage Control | Issuer restrictions on card application usage. |
| 313 | 2 | BH | Cryptogram Information Data | Indicates the cryptogram type (TC, ARQC, or AAC). |
| 315 | 6 | BH | CVM Results | Results of the last Cardholder Verification Method (CVM) performed. |
| 321 | 32 | BH | Application identifier | Application identifier as defined in ISO/IEC 7816-5. |
| 353 | 4 | BH | ICC application version number | Version number for compatibility between the card application and the terminal. Corresponds to EMV tag 9F08. |
| 357 | 4 | BH | Transaction status information | Status of EMV processing. |
| 361 | 2 | BH | Terminal type | Terminal type indicator. |
| 363 | 6 | BH | EMV terminal capabilities | Terminal capability indicators. |
| 369 | 2 | N | POS entry mode | Two-digit code. Digit 1: entry method (0 = not used; 1 = swipe; 2 = keyed; 3 = ICC; 4 = recovered keyed; 5 = recovered electronic; 6 = information advice; 7 = ICC downgrade; 8 = ICC swipe failure; 9 = contactless). Digit 2: cardholder verification (0 = not used; 1 = signature; 2 = PIN; 3 = alternate CVM; 4 = Unattended Payment Terminal (UPT), no CVM; 5 = UPT with PIN; 6 = UPT with alternate CVM; 7 = not present; 8 = no CVM contactless; 9 = reserved). |
| 371 | 26 | A | Reserved | Space-fill. |
| 397 | 30 | A | Issuer Action Codes (IAC) | Three blocks of 10 characters each, in the order Denial, Online, Default. Space-fill if not used. |
| 427 | 3 | A | Reserved | Space-fill. |

## Subrecord formats

Subrecords are optional supplemental records that follow their companion
transaction records in the V-file. Each subrecord type is identified by
a two-character transaction code at positions 20–21 of the subrecord.
The following table summarizes the available subrecord types.

| Code | Subrecord | Positions | When to include |
| :- | :- | :- | :- |
| `05` | Integrated Terminal | 1–273 | Transactions processed by integrated terminals (for example, Mastercard, Visa, Diners). |
| `06` | UPI and JCB | 1–90 | JCB (Japan Credit Bureau) and UPI (China UnionPay International) card transactions. |
| `07` | MCP and Supplemental Reporting | 1–90 | Multi-Currency Pricing (MCP) and DCC product categories for supplemental reporting. |
| `10` | ICC Addendum | 1–90 | When the application currency code from the card chip (EMV tag 9F42) must be reported. |
| `17` | AMEX Hospitality | 1–169 | American Express hospitality (lodging) transactions. Mandatory for AMEX hospitality V-file submissions. |
| `18` | Credentials on File | 1–90 | Transactions using stored cardholder credentials (Visa and Mastercard). |
| `39` | Contactless | 1–300 | Contactless transactions at terminals configured with Form Factor Indicator (FFI) support. |
| `40` | Pay by Instalment | 1–110 | Instalment transactions (Visa and Mastercard). |
| `41` | 3D Secure | 1–130 | All 3D Secure version 1, 3D Secure version 2, and non-3D-Secure eCommerce transactions. |

> [!NOTE]
>
> Only one subrecord of each type is permitted per transaction. The
> `Total number of subrecords` field in Segment 2 Type 1 must match the
> number of companion subrecords present for each transaction record.

### `05` Integrated Terminal subrecord

The Integrated Terminal subrecord carries additional authorisation and
scheme data for transactions processed through integrated terminals. It
occupies positions 1 through 273 of the subrecord line and is placed
immediately after its companion transaction record. The following table
describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 4 | N | Subrecord counter | Position of this subrecord relative to other subrecords for the same transaction. The first subrecord has the value `0001`. Zero-fill, right-justify. |
| 5 | 15 | AN | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | Transaction code | Always `05`. |
| 22 | 9 | AN L | MC Banknet reference number | Mastercard authorisation reference from DE 63 of the authorisation response. Left-justify, space-fill if not used. Recommended to avoid Mastercard non-compliance fees. |
| 31 | 4 | AN | MC Banknet date | Mastercard authorisation date in `MMDD` format. Required when MC Banknet reference number is populated. |
| 35 | 15 | AN | Authorisation date and time | Date and time the authorisation was received. Format: `YYMMDD HH:MM:SS` (note the space between date and time). |
| 50 | 1 | AN | Reserved | Reserved. Space-fill. |
| 51 | 15 | AN RZ | Visa transaction identifier | Visa transaction identifier from the authorisation response. For AMEX, the transaction identifier from the authorisation response. Zero-fill, right-justify if not available. |
| 66 | 3 | N | Authorisation currency code | ISO 4217 three-digit numeric currency code in which the transaction was authorised. Zero-fill if not required. |
| 69 | 12 | AN L | Retrieval reference number | Numeric reference used to identify and track messages related to the transaction. Left-justify, space-fill. |
| 81 | 3 | AN | Time zone | Hours offset from GMT. For example, `+01`, `-04`, `+00`. |
| 84 | 7 | N R | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |
| 91 | 4 | AN | Visa validation code | Returned in the authorisation response. Corresponds to APACS field SCHEME REFERENCE DATA. Zero-fill or space-fill for UK and European regions (field no longer returned as of April 2018). |
| 95 | 2 | AN | Visa card level result | Visa card product identifier from the authorisation response. Space-fill if not used. |
| 97 | 15 | AN | Diners reference network | Diners card reference data (NRID value from DE 123 of the authorisation message). Zero-fill if not used. |
| 112 | 6 | AN | Additional data codes | Association for Payment Clearing Services (APACS) Standard 70 Book 2 response additional data codes. |
| 118 | 4 | AN | Terminal version number | EMV terminal application version number. Corresponds to EMV tag 9F09. |
| 122 | 2 | N | Mastercard transit transaction type | Mastercard transit transaction type (EMV tag 52). Zero-fill if not used. See [Mastercard transit transaction types](#mastercard-transit-transaction-types). |
| 124 | 2 | N | Mastercard transportation mode | Mastercard transportation mode (EMV tag 53). Zero-fill if not used. |
| 126 | 12 | BH | Point of Interaction Capabilities | Bitmapped data indicating terminal environment (EMV tag 56). Space-fill if not used. |
| 138 | 12 | BH | Payment Device Data | Bitmapped data indicating the cardholder's payment device form factor (EMV tag 57). Space-fill if not used. |
| 150 | 3 | AN | Mastercard/Masterpass Digital Wallet Identifier | Mastercard digital wallet operator identifier (EMV tag 58). Space-fill if not used. |
| 153 | 4 | N | Multiple Clearing Record | Shipping/settlement sequence and total count for split-settlement transactions (EMV tag 59). Space-fill if not used. |
| 157 | 9 | AN | Reserved | Reserved. Space-fill. |
| 166 | 6 | BH | Supplemental Transaction Data | Bitmapped additional data values (EMV tag 61). Variable length 2–6 characters. Space-fill if not used. |
| 172 | 1 | AN | Card Verification Result code | CVV2 (Visa) or CVC2 (Mastercard) result code from the authorisation response. Space-fill if not used. |
| 173 | 1 | AN | Address Verification Result code | AVS result code from the authorisation response. Space-fill if not used. |
| 174 | 22 | AN L | Mastercard Transaction Link Identifier (TLID) | Mastercard authorisation reference from DE 105 subelement 001 of the authorisation response (EMV tag 62). Left-justify, space-fill if not used. |
| 196 | 78 | AN | Reserved | Reserved. Space-fill. |

#### Mastercard transit transaction types

The following table lists the allowed values for the Mastercard transit
transaction type field.

| Value | Description |
| :- | :- |
| `01` | Prefunded |
| `02` | Realtime authorised |
| `03` | Post-authorised aggregated |
| `04` | Authorised aggregated split clearing |
| `05` | Other |
| `06` | Post-authorised aggregated Maestro |
| `07` | Debt recovery |

### `06` UPI and JCB subrecord

The UPI and JCB subrecord is required for JCB (Japan Credit Bureau) and
UPI (China UnionPay International) card transactions. It is formatted
under the Association for Payment Clearing Services (APACS) 40 standard
and occupies positions 1 through 90 of the subrecord line. The following table describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 4 | N | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, right-justify. |
| 5 | 15 | AN | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | Transaction code | Always `06`. |
| 22 | 6 | N | System trace number | Space-fill if not used. |
| 28 | 2 | N | Transaction initiating channel | Channel through which the transaction was initiated. For example: `01` = not defined; `02` = ATM; `04` = POS; `05` = electronic data capture; `07` = internet; `08` = wireless device. Zero-fill if not used. |
| 30 | 42 | BH | Issuer script result | Space-fill if not used. |
| 72 | 1 | N | Cardholder verification | Same as POS Entry Mode digit 2. One of: `0` = not used; `1` = customer present, signature; `2` = customer present, PIN; `3` = customer present, alternative CVM; `7` = customer not present; `8` = no verification. |
| 73 | 2 | N | Card scheme code | Two-digit code identifying the card brand. For example: `22` = Mastercard; `17` = Visa; `61` = UnionPay; `10` = JCB. Zero-fill if not used. |
| 75 | 9 | AN | Reserved | Reserved. Space-fill. |
| 84 | 7 | N R | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |

### `07` MCP and Supplemental Reporting subrecord

The MCP and Supplemental Reporting subrecord supports Multi-Currency
Pricing (MCP) and DCC transactions. It contains the foreign exchange
method, currency offered, and an optional cashier identifier for
per-cashier reporting. It occupies positions 1 through 90 of the
subrecord line. The following table describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 4 | N | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, right-justify. |
| 5 | 15 | AN | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | Transaction code | Always `07`. |
| 22 | 4 | N R | MCP offered currency | ISO 4217 four-digit numeric currency code of the currency offered to the cardholder. For example, `0978` for EUR, `0840` for USD. Zero-fill if not used. |
| 26 | 1 | AN | Final currency detection method | Method used to detect cardholder currency. One of: `1` = not available; `2` = IP geolocation; `3` = browser language; `4` = dropdown list; `5` = user profile; `6` = cardholder billing address; `7` = DCC; `8` = cookie. Zero-fill if not used. |
| 27 | 3 | N R | Country of residence | ISO 3166-1 numeric country code for the cardholder's permanent residency. Zero-fill if not used. |
| 30 | 11 | AN L | Cashier ID | Identifier for the point-of-sale operator. Useful for per-cashier hit rate reporting. Space-fill if not used. |
| 41 | 43 | AN | Reserved | Reserved. Space-fill. |
| 84 | 7 | N R | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |

### `10` ICC Addendum subrecord

The ICC Addendum subrecord captures the application currency code stored
on the integrated chip of the payment card (EMV tag 9F42). It occupies
positions 1 through 90 of the subrecord line. The following table
describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 4 | N | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, left-justify. |
| 5 | 15 | AN | Reserved | Space-fill or zero-fill. |
| 20 | 2 | N | Transaction code | Always `10`. |
| 22 | 4 | N RZ | Application currency code | Four-digit ISO 4217 numeric currency code stored on the card chip. For example, `0978` for EUR, `0826` for GBP. Zero-fill, right-justify. |
| 26 | 58 | AN | Reserved | Space-fill or zero-fill. |
| 84 | 7 | N R | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |

### `17` AMEX Hospitality subrecord

The AMEX Hospitality subrecord is mandatory for American Express
hospitality (lodging) V-file submissions. It is based on the Transaction
Advice Addendum (TAA) record for the lodging industry as defined in the
AMEX Global Financial Submission Guide. This subrecord must not be
submitted alongside any other industry-specific TAA transaction. It
occupies positions 1 through 169 of the subrecord line. The following
table describes each field.

| Position | Length | Type | M/O | Field | Description |
| :- | :- | :- | :- | :- | :- |
| 1 | 4 | N | M | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, left-justify. |
| 5 | 15 | AN | M | Reserved | Space-fill or zero-fill. |
| 20 | 2 | N | M | Transaction code | Always `17`. |
| 22 | 3 | AN | M | Record type | Always `TAA` in uppercase. Identifies the record as a Transaction Advice Addendum. |
| 25 | 8 | N R | M | TAA record number | Sequential record number incremented by 1 for each TAA subrecord in the file. Maximum value `09999999`. Zero-fill, right-justify. |
| 33 | 15 | N | M | Transaction identifier | Unique tracking number from the authorisation response. Use the first identifier when multiple authorisations were obtained. |
| 48 | 2 | AN | M | Format code | Always `11`. Identifies this TAA as a lodging industry record. |
| 50 | 2 | AN | M | Addenda type code | Always `03`. Identifies this as an industry-specific detail addendum. |
| 52 | 1 | N | M | Lodging special program code | One of: `1` = lodging (default); `2` = no-show reservation; `3` = advanced deposit. |
| 53 | 8 | N | M | Lodging check-in date | Check-in date in `YYYYMMDD` format. |
| 61 | 8 | N | M | Lodging check-out date | Check-out date in `YYYYMMDD` format. Must be greater than or equal to check-in date. |
| 69 | 3 | N | M | Reserved | Zero-fill. |
| 72 | 12 | N | O | Lodging room rate 1 | Nightly rate for one room in unsigned minor units. No decimal point. In the transaction currency specified in Segment 2 field 18. Zero-fill if not used. |
| 84 | 7 | N R | M | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |
| 91 | 2 | N | O | Number of nights at room rate 1 | Number of nights charged at room rate 1. Zero-fill if not used. |
| 93 | 3 | N | M | Reserved | Zero-fill. |
| 96 | 12 | N | O | Lodging room rate 2 | Nightly rate for two rooms in unsigned minor units. Zero-fill if not used. |
| 108 | 2 | N | O | Number of nights at room rate 2 | Number of nights charged at room rate 2. Zero-fill if not used. |
| 110 | 3 | N | M | Reserved | Zero-fill. |
| 113 | 12 | N | O | Lodging room rate 3 | Nightly rate for three rooms in unsigned minor units. Zero-fill if not used. |
| 125 | 2 | N | O | Number of nights at room rate 3 | Number of nights charged at room rate 3. Zero-fill if not used. |
| 127 | 26 | AN L | O | Lodging renter name | Name of the person or entity charged for the reservation. Uppercase letters only. Space-fill if not used. |
| 153 | 12 | AN L | M | Lodging folio number | Folio number assigned to the lodging stay. Uppercase letters only. Space-fill, left-justify. |
| 165 | 5 | N | M | Reserved | Zero-fill. |

### `18` Credentials on File subrecord

The Credentials on File subrecord must be present when a transaction
uses stored cardholder credentials. It conforms to Visa and Mastercard
stored credential indicators and is required from 14 September 2019
under Payment Services Directive 2 (PSD2) Strong Customer Authentication
(SCA) rules. It occupies positions 1 through 90 of the subrecord line.
The following table describes each field.

| Position | Length | Type | M/O | Field | Description |
| :- | :- | :- | :- | :- | :- |
| 1 | 4 | N | M | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, left-justify. |
| 5 | 15 | AN | M | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | M | Transaction code | Always `18`. |
| 22 | 1 | AN | M | Card acceptor/cardholder agreement | Method of cardholder consent. One of: `C` = unscheduled payment; `I` = instalment; `N` = not applicable; `R` = recurring payment. |
| 23 | 1 | AN | M | Cardholder not present condition | One of: `C` = cardholder not present (unspecified); `M` = mail order; `N` = not applicable (cardholder present); `T` = telephone order; `E` = eCommerce; `A` = application-initiated eCommerce. |
| 24 | 1 | AN | M | Reserved | Reserved for UK Cards Association. Space-fill. |
| 25 | 1 | AN | M | Stored payment details indicator | One of: `F` = payment details stored for the first time; `N` = not applicable; `S` = using previously stored payment details. |
| 26 | 20 | AN | M | Reserved | Reserved for UK Cards Association. Space-fill. |
| 46 | 38 | AN | M | Reserved | Reserved. Space-fill. |
| 84 | 7 | N R | M | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |

### `39` Contactless subrecord

The Contactless subrecord is required for all transactions where a
contactless consumer device is used at a terminal configured to support
the Form Factor Indicator (FFI). It occupies positions 1 through 300 of
the subrecord line. The following table describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 4 | N | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, right-justify. |
| 5 | 15 | AN | Reserved | Reserved. Space-fill. |
| 20 | 2 | AN | Transaction code | Always `39`. |
| 22 | 62 | A | Reserved | Reserved. Space-fill. |
| 84 | 7 | AN | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |
| 91 | 70 | AB | Contactless Form Factor | Contactless form factor data. For Visa and Mastercard, this is a pass-through from EMV tag 9F6E. For American Express, from EMV tag 9F67. Encode in BER-TLV format. Space-fill if not used. Left-justify. |
| 161 | 70 | AB | Contactless Discretionary Data | Scheme-specific discretionary data. For Visa, this is the content of EMV tag 9F7C. Encode the length component to represent the binary data length. Space-fill if not used. Left-justify. |
| 231 | 70 | AN | Reserved | Reserved. Space-fill. |

### `40` Pay by Instalment subrecord

The Pay by Instalment subrecord is required when an instalment
transaction is performed and must conform to Visa and Mastercard
instalment data fields. It occupies positions 1 through 110 of the
subrecord line. The following table describes each field.

| Position | Length | Type | M/O | Field | Description |
| :- | :- | :- | :- | :- | :- |
| 1 | 4 | N | M | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, right-justify. |
| 5 | 5 | N | O | Annual percentage rate | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 10 | 1 | A | O | Instalment funding type | Used by Mastercard. One of: `I` = issuer funded; `M` = merchant funded; `A` = acquirer funded; `C` = co-branded merchant funded; `F` = issuer-merchant co-funded. Space-fill if not used. |
| 11 | 5 | N | O | Interest rate | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 16 | 2 | N | O | Number of instalments | Used by Visa and Mastercard. Space-fill or zero-fill, right-justify. |
| 18 | 2 | A | O | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | M | Transaction code | Always `40`. |
| 22 | 12 | N | O | First instalment amount | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 34 | 12 | N | O | Subsequent instalment amount | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 46 | 12 | N | O | Total instalment fee | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 58 | 12 | N | O | Overall instalment agreement amount | Used by Mastercard. Space-fill or zero-fill, right-justify. |
| 70 | 3 | A | O | Instalment billing currency | Used by Mastercard. ISO 4217 three-letter alphabetic currency code. Space-fill if not applicable. |
| 73 | 11 | A | O | Reserved | Reserved. Space-fill. |
| 84 | 7 | N | M | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |
| 91 | 2 | N | O | Instalment sequence number | Used by Visa. Sequence number of this instalment relative to the total. Space-fill or zero-fill, right-justify. |
| 93 | 5 | N | O | Commission rate | Used by Mastercard. Zero-fill, right-justify. |
| 98 | 1 | A | O | Commission sign | Used by Mastercard where a commission rate or amount is present. One of: `C` = credit issuer; `D` = debit issuer. Space-fill if not used. |
| 99 | 12 | N | O | Commission amount | Zero-fill, right-justify. |

### `41` 3D Secure subrecord

The 3D Secure subrecord is mandatory for all 3D Secure version 1, 3D
Secure version 2, and non-3D-Secure eCommerce transactions. It occupies
positions 1 through 130 of the subrecord line. The following table
describes each field.

| Position | Length | Type | M/O | Field | Description |
| :- | :- | :- | :- | :- | :- |
| 1 | 4 | N | M | Subrecord counter | Position of this subrecord. The first subrecord has the value `0001`. Zero-fill, left-justify. |
| 5 | 15 | AN | M | Reserved | Reserved. Space-fill. |
| 20 | 2 | N | M | Transaction code | Always `41`. |
| 22 | 2 | N | M | 3D Secure program protocol | Protocol version. One of: `01` = 3D Secure version 1; `02` = 3D Secure version 2. Zero-fill for non-3D-Secure and non-eCommerce transactions. |
| 24 | 32 | AN L | M | Cardholder Authentication Value | Result of 3D Secure authentication (UCAF or CAVV). Must be populated for all 3D Secure version 2 transactions. Left-justify, space-fill. |
| 56 | 28 | AN | M | Reserved | Reserved. Space-fill. |
| 84 | 7 | N R | M | Record sequence number | Position of this record within the file. Zero-fill, right-justify. |
| 91 | 36 | AN L | M | Directory Server Transaction ID | Transaction identifier supplied by the 3D Secure server. Left-justify, space-fill. |
| 127 | 4 | AN | M | SCA Exemption Indicator | Strong Customer Authentication (SCA) exemption code, if applicable. Refer to APACS 70 Standards Book 3 for valid values. |

## Net summary record

A net summary record must be included for each terminal-currency
combination present in the file. Summary records use transaction code
`E4` (sales exceed refunds), `E5` (refunds exceed sales), or `E6`
(cash advance). The net summary record line occupies positions 1 through
90\. The following table describes each field.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 19 | N | Reserved | Zero-fill. |
| 20 | 2 | AN | Transaction code | One of: `E4` = net sales summary (sales at or above refunds); `E5` = net refund summary (refunds exceed sales); `E6` = net cash advance summary. |
| 22 | 11 | AN R | Terminal ID | Same value as the terminal ID in the companion transaction records. Space-fill, right-justify. |
| 33 | 4 | N R | Currency code | ISO 4217 four-digit numeric currency code of the transactions in this summary. For example, `0978` for EUR. |
| 37 | 11 | N R | Net amount | Net base equivalent of the summarized transactions in unsigned minor units. For E4: net of J1/P1 minus J2/P2. Right-justify. |
| 48 | 11 | N R | Value of debit items | Total value of J1/P1/K1 transactions in the base currency. Right-justify. |
| 59 | 11 | N R | Value of credit items | Total value of J2/P2/K2 transactions in the base currency. Right-justify. |
| 70 | 7 | N R | Count of debit items | Number of J1/P1/K1 transactions. Right-justify. |
| 77 | 7 | N R | Count of credit items | Number of J2/P2/K2 transactions. Right-justify. |
| 84 | 7 | N R | Sequence number | Position of this record within the file. Right-justify. |

## Net claim record

A single net claim record exists per merchant. The record uses
transaction code `E7` when refunds exceed sales (payment by merchant)
or `E8` when sales equal or exceed refunds (claim by merchant). The
format differs depending on whether the merchant ID is 11 characters
or fewer, or between 12 and 16 characters.

> [!NOTE]
>
> Do not mix short and long merchant IDs in the same V-file. A file must
> contain all merchant IDs with 11 characters or fewer, or all merchant
> IDs with 12 characters or more.

### Short merchant IDs (11 characters or fewer)

The following table describes the net claim record format for merchant
IDs up to 11 characters. The record line occupies positions 1 through 90.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 19 | N | Reserved | Zero-fill. |
| 20 | 2 | AN | Transaction code | One of: `E7` = payment by merchant (refunds exceed sales); `E8` = claim by merchant (sales equal or exceed refunds). |
| 22 | 11 | AN R | Merchant ID | Unique merchant identifier (also referred to as the Merchant Originator tag). Space-fill, right-justify. |
| 33 | 4 | A | Reserved | Space-fill. |
| 37 | 11 | N R | Net amount | Net base equivalent for the file in unsigned minor units. Right-justify. |
| 48 | 11 | N R | Value of all debit summary items | Net amount from all E4 summary records. Right-justify. |
| 59 | 11 | N R | Value of all credit summary items | Net amount from all E5 summary records. Right-justify. |
| 70 | 7 | N R | Count of debit summaries | Number of E4 summary records. Right-justify. |
| 77 | 7 | N | Count of credit summaries | Number of E5 summary records. |
| 84 | 7 | N R | Sequence number | Position of this record within the file. Right-justify. |

### Long merchant IDs (12 to 16 characters)

The following table describes the net claim record format for merchant
IDs of 12 to 16 characters. The merchant ID occupies positions 4 through
19\. The record line occupies positions 1 through 90.

| Position | Length | Type | Field | Description |
| :- | :- | :- | :- | :- |
| 1 | 3 | N | Reserved | Zero-fill. |
| 4 | 16 | AN | Merchant ID | Unique merchant identifier (up to 16 characters). Space-fill or zero-fill unused positions. |
| 20 | 2 | AN | Transaction code | One of: `E7` = payment by merchant; `E8` = claim by merchant. |
| 22 | 11 | N | Reserved | Zero-fill. |
| 33 | 4 | A | Reserved | Space-fill. |
| 37 | 11 | N R | Net amount | Net base equivalent for the file in unsigned minor units. Right-justify. |
| 48 | 11 | N R | Value of all debit summary items | Net amount from all E4 summary records. Right-justify. |
| 59 | 11 | N R | Value of all credit summary items | Net amount from all E5 summary records. Right-justify. |
| 70 | 7 | N R | Count of debit summaries | Number of E4 summary records. Right-justify. |
| 77 | 7 | N | Count of credit summaries | Number of E5 summary records. |
| 84 | 7 | N R | Sequence number | Position of this record within the file. Right-justify. |

## Transaction rejection codes

Fexco includes a rejection code in the confirmation file for each
rejected transaction in a partially rejected V-file. The following
tables list codes by record section.

> [!NOTE]
>
> Rejection codes `E4` and `E8` also appear as transaction codes in the net
> summary and net claim records. In the subrecord errors table, they are
> rejection codes only.

### General errors

The following codes indicate general validation failures not specific
to a single segment.

| Code | Rejection reason |
| :- | :- |
| `01` | Invalid credit card number |
| `02` | Transaction code and record length do not match. J1/J2 records must be 173 bytes; P1/P2 records must be 429 bytes; K1/K2 records must be 463 bytes. |
| `03` | Invalid merchant ID |
| `04` | Invalid expiry date. Not checked on P1 (ICC) transactions. |
| `05` | Foreign amount is zero |
| `06` | Invalid transaction date |
| `09` | Invalid switch card issue — digit 1 |
| `10` | Invalid switch card issue — digit 2 |
| `11` | Invalid customer instructions |
| `12` | Invalid exchange rate |
| `13` | Invalid method of authorisation |
| `14` | Invalid type of purchase transaction |
| `15` | Invalid exchange rate for cash advance amount |
| `17` | Invalid combination of foreign currency, exchange rate, and base currency amount |
| `18` | Invalid currency code |
| `19` | Net amount is incorrect |
| `20` | Value of debit items does not match the sum of debit transaction amounts |
| `21` | Value of credit items does not match the sum of credit transaction amounts |
| `22` | Value of debit items exceeds value of credit items. Transaction code must be `E4`. |
| `23` | Value of credit items exceeds value of debit items. Transaction code must be `E5`. |
| `24` | Count of credit items is incorrect |
| `25` | Count of debit items is incorrect |
| `26` | Missing or incomplete airline leg data |
| `27` | Expiry date occurs before transaction date |
| `28` | Invalid data source |

### Segment 1 errors

The following codes indicate field validation failures in Segment 1.

| Code | Rejection reason |
| :- | :- |
| `31` | Invalid transaction code |
| `32` | Invalid terminal ID format |
| `34` | Invalid base amount |
| `36` | Invalid transaction time |
| `37` | Invalid authorisation code |
| `38` | Invalid transaction reference |
| `3A` | Invalid terminal type |
| `3C` | Invalid sequence number |

### Segment 4 errors

The following codes indicate field validation failures in Segment 4.

| Code | Rejection reason |
| :- | :- |
| `40` | Invalid application PAN sequence number |
| `41` | Invalid authorisation response code |
| `42` | Invalid cryptogram transaction amount |
| `44` | Invalid terminal transaction date |
| `45` | Invalid transaction currency code |
| `46` | Invalid terminal country code |
| `47` | Invalid transaction cryptogram |
| `48` | Invalid Application Interchange Profile (AIP) |
| `49` | Invalid Application Transaction Counter (ATC) |
| `4A` | Invalid unpredictable number |
| `4B` | Invalid Terminal Verification Result (TVR) |
| `4C` | Invalid Issuer Application Data (IAD) |
| `4D` | Invalid application usage control |
| `4E` | Invalid cryptogram information data |
| `4F` | Invalid CVM results |
| `4G` | Invalid application identifier |
| `4H` | Invalid application version |
| `4I` | Invalid transaction status information or cryptogram transaction type |
| `4J` | Invalid terminal type |
| `4K` | Invalid terminal capabilities |
| `4L` | Invalid POS entry mode |
| `4M` | Invalid issuer action codes |

### Segment 2 Type 1 errors

The following codes indicate field validation failures in Segment 2
Type 1.

| Code | Rejection reason |
| :- | :- |
| `50` | Invalid narrative line 1 |
| `51` | Invalid terminal identifier |
| `52` | Invalid cash advance amount |
| `53` | Invalid currency amount |
| `54` | Invalid transaction currency code |
| `55` | Invalid EPOS transaction number |
| `56` | Invalid EPOS identifier |
| `57` | Invalid additional data identifier |

### Airline segment errors

The following codes indicate field validation failures in Segment 2
Type 4 or Segment 3 Type 5.

| Code | Rejection reason |
| :- | :- |
| `60` | Invalid ticket number |
| `61` | Invalid travel agency code |
| `62` | Invalid ticket agency name |
| `63` | Invalid number of legs |
| `64` | Invalid format type |
| `65` | Invalid passenger name |
| `66` | Invalid customer reference number |
| `67` | Invalid trip leg 1 |
| `68` | Invalid trip leg 2 |
| `69` | Invalid trip leg 3 |
| `6A` | Invalid trip leg 4 |

### Subrecord errors

The following codes indicate validation failures in subrecords.

| Code | Rejection reason |
| :- | :- |
| `71` | Invalid transaction code for subrecord |
| `72` | Invalid subrecord length |
| `73` | Invalid subrecord counter |
| `74` | Duplicate subrecord type. Only one subrecord of each type is permitted per transaction. |
| `80` | Invalid offered currency in the MCP subrecord (type `07`) |
| `81` | Invalid final currency detection method in the MCP subrecord (type `07`) |
| `82` | Invalid country of residence in the MCP subrecord (type `07`) |
| `B0` | Invalid contactless form factor in the Contactless subrecord (type `39`) |
| `B1` | Invalid contactless discretionary data in the Contactless subrecord (type `39`) |
| `C0` | Invalid application currency code in the ICC Addendum subrecord (type `10`) |
| `D0` | Invalid lodging check-in date in the AMEX Hospitality subrecord (type `17`) |
| `D1` | Invalid lodging check-out date in the AMEX Hospitality subrecord (type `17`) |
| `D2` | Invalid lodging room rate 1 in the AMEX Hospitality subrecord (type `17`) |
| `D3` | Invalid number of nights at room rate 1 in the AMEX Hospitality subrecord (type `17`) |
| `D4` | Invalid lodging room rate 2 in the AMEX Hospitality subrecord (type `17`) |
| `D5` | Invalid number of nights at room rate 2 in the AMEX Hospitality subrecord (type `17`) |
| `D6` | Invalid lodging room rate 3 in the AMEX Hospitality subrecord (type `17`) |
| `D7` | Invalid number of nights at room rate 3 in the AMEX Hospitality subrecord (type `17`) |
| `D8` | Invalid lodging folio number in the AMEX Hospitality subrecord (type `17`) |
| `E0` | Invalid 3D Secure program protocol in the 3D Secure subrecord (type `41`) |
| `E1` | Invalid cardholder authentication value in the 3D Secure subrecord (type `41`) |
| `E2` | Invalid directory server transaction ID in the 3D Secure subrecord (type `41`) |
| `E3` | Invalid SCA exemption indicator in the 3D Secure subrecord (type `41`) |
| `E4` | Invalid payment attributes in the Credentials on File subrecord (type `18`) |
| `E8` | Invalid Pay by Instalment field in the Pay by Instalment subrecord (type `40`) |

## File rejection codes

Fexco includes a file rejection code in the confirmation file when an
entire V-file is rejected. The following table describes each code.

| Code | Description |
| :- | :- |
| `R01` | Invalid filename |
| `R02` | Invalid merchant ID in filename |
| `R03` | Invalid date in filename |
| `R04` | Invalid sequence number in filename |
| `R05` | File has already been uploaded |
| `R06` | One or more of the following structural problems: invalid or missing VHL record; invalid or missing UTL record; sequence number mismatch between VHL and filename; invalid UHL record; invalid UTL totals; invalid net claim totals; invalid sequence numbers in transactions |
| `R13` | Invalid transaction record length |
| `R14` | Invalid net summary record length |
| `RXX` | Exceptional error: no transactions found in file; no E4 summary records found; or internal processing error |

## Next steps

Use the following resources to continue after reviewing this reference.

* [Build and submit a V-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/v-file.md):
  follow the step-by-step guide to construct, encrypt, and submit
  your V-file.
* [How transaction import works](https://docs.fexco.com/dcc/guides/transaction-import/how-it-works.md):
  review the purpose of transaction import and the daily file cycle.
* [Choose a file format](https://docs.fexco.com/dcc/guides/transaction-import/file-format.md):
  compare the V-file, XML I-file, and I-file formats.
* [Troubleshoot transaction file errors](https://docs.fexco.com/dcc/guides/transaction-import/troubleshoot.md):
  diagnose and resolve common submission errors.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.