> ## 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. # Transaction inclusion and exclusion rules > Rules for which transactions to include in or exclude from the End of Day (EOD) file, for Single Message and Dual Message environments. The End of Day file is a daily record of financial transactions where [DCC](https://docs.fexco.com/dcc/guides/getting-started/what-is-dcc.md) was offered to the cardholder. Fexco uses it to reconcile and settle DCC activity between the acquirer or processor and the DCC provider. This page explains which transactions you must include in the file and which you must exclude. ## Inclusion rules overview A batch process generates the EOD file. It runs in parallel to, and independently of, any clearing files that the acquirer or processor submits to the card schemes. The EOD file is not a copy of the scheme clearing file and is not routed through the schemes. Its contents must still be consistent with the transactions cleared to the schemes, so that Fexco can reconcile both. A transaction must be included in the EOD file when all of the following apply: * It is a financial transaction, meaning it results in a posting to the cardholder's account. * The issuer approved it, or it was approved on the issuer's behalf (for example, stand-in processing). * DCC was offered to the cardholder, and the cardholder either accepted or declined the offer. The two DCC outcomes are defined as follows: | Outcome | Description | | :- | :- | | DCC accepted (opt-in) | The transaction was processed in the cardholder's billing currency at the quoted DCC rate. | | DCC declined (opt-out) | The cardholder opted out, and the transaction was processed in the merchant's local currency. | Each record must include the DCC outcome (accepted or declined) so that Fexco can identify both scenarios. ### How opt-in and opt-out transactions differ in the file When a cardholder accepts DCC, the file record shows the converted currency, amount, and exchange rate. When a cardholder declines DCC, the transaction is processed in the merchant's base currency, so the file record reflects that. The following table compares the field values for each outcome in the XML I-file. | Field | DCC accepted (opt-in) | DCC declined (opt-out) | | :- | :- | :- | | `transactionCurrency` | Cardholder's home currency (for example, `NZD`) | Merchant's base currency (for example, `EUR`) | | `transactionAmount` | Converted amount in cardholder's currency (for example, `106.16`) | Same as `baseAmount` (for example, `100.00`) | | `exchangeRate` | DCC rate (for example, `1.06164`) | `1.00` | | `transactionCode` | `debit` for a sale, `credit` for a refund | `debit` for a sale, `credit` for a refund | For the legacy I-file and V-file formats, the same principle applies: an opt-out record uses the base currency as the transaction currency, the base amount as the transaction amount, and an exchange rate of `00000001.0000`. ## Processing cycle requirements The EOD file must align with the 24-hour processing cycle that the acquirer or processor uses, including its cut-off time. This ensures that Fexco can match the file to the transactions in each cycle. You must include each transaction once only, in the cycle in which it was completed (Single Message) or presented for clearing (Dual Message). ## Single Message rules In a Single Message environment, authorization, clearing, and settlement are completed in one online message. You include transactions based on the outcome of the financial message itself. The following table lists the message type indicators (MTIs) and the rule for each one. | MTI | Description | Rule | | :- | :- | :- | | `0200` / `0210` | Financial transaction request and response. | Include where the response indicates approval or partial approval. Exclude where the response indicates a decline. For partial approvals, see [Refund and partial approval rules](#refund-and-partial-approval-rules). | | `0220` / `0230` | Financial transaction advice and response. | Include approved advices, for example stand-in approvals, preauthorization completions, and force-post transactions. | | `0400` / `0420` | Reversal request and advice. | Include full and partial reversals where the original transaction is included in the EOD file. Reversals must carry the same DCC currency and rate as the original. A reversal appears in the file for the cycle in which it is processed. | | Repeat messages (for example, `0201`, `0221`, `0401`, `0421`) | Repeats of an earlier message. | Exclude where the original message was already included, to avoid duplicates. | | `01xx`, `03xx`, `06xx`, `08xx` | Authorization, file update, administrative, and network management messages. | Exclude. | A request and response pair must produce one record only. ## Dual Message rules In a Dual Message environment, authorization and clearing are separate processes. The DCC decision is captured at authorization, but you include a transaction in the EOD file only when it is presented for clearing. The following table lists the message types and the rule for each one. | Message | Rule | | :- | :- | | First presentment (purchases and refunds) | Include where DCC was offered at authorization. Refunds must be linked to an original DCC transaction. | | Second presentment or re-presentment | Exclude. These belong to the dispute cycle. | | Authorization request and response (`0100` / `0110`) | Exclude. These do not post to the cardholder's account. | | Authorization reversal (`0400` / `0420`) | Exclude. | | Chargebacks and other dispute messages | Exclude. | | File header and trailer, addenda, reconciliation, and administrative records | Exclude. | | Fee collection records | Exclude. | You must not include authorizations and preauthorizations that are never presented for clearing. ## Refund and partial approval rules Refunds and partial approvals follow the same rules in Single Message and Dual Message environments. Refunds (credits) must be included where they are linked to an original DCC transaction. You must exclude standalone refunds that have no linked original DCC transaction. Partially approved transactions must be included for the approved amount only. Fexco quotes the DCC rate and converted amount to the cardholder on the full transaction amount. A partial approval can therefore create a mismatch between what the cardholder accepted and what is processed. We recommend one of the following approaches: * The host or terminal handles partial approvals appropriately for DCC transactions. * Where this is not possible, you do not send the partial approval indicator on the authorization request for DCC transactions. ## Transactions always excluded You must exclude the following transactions regardless of message type: * Transactions where DCC was not offered. For example, the card is ineligible, the card was issued in the merchant's local currency, the merchant or merchant ID (MID) is not enabled for DCC, or the rate request failed or timed out. * Declined, failed, cancelled, or voided transactions, together with the corresponding sale. * Preauthorizations, including incremental preauthorizations. You include only the completion (Single Message) or the first presentment (Dual Message). * Duplicate or repeat submissions of a transaction that is already included. ## Next steps After you confirm which transactions to include, build and submit your file: * [Build and submit an XML I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md): structure, validate, encrypt, and submit an XML transaction file. * [Build and submit an I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/i-file.md): structure and submit a fixed-length information-only file. * [Build and submit a V-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/v-file.md): structure and submit a fixed-length settlement file. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.