> ## Documentation Index > Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt > Use this file to discover all available pages before exploring further. # Report field reference > This page collects the field-by-field meaning of both daily settlement files (the authorization report and the transaction report) in one place, as the reference you load your reconciliation against. For how to retrieve the reports, see Reconciliation overview; for how each file is generated and what a sample line looks like, see Authorization report and Transaction report. ## 📄 Guide Whether you run end-of-day reconciliation, verify user limits, or load every movement of funds on a card into a data warehouse, the settlement files DCS generates each day give you an authoritative source. As a licensed issuer with its own BINs, DCS generates two **full** files per partner every day, the authorization report and the transaction report, and stores them in AWS S3 for you to fetch a download link by date. This page explains what every column in those two files means. Once you know the fields, you can turn any single line back into a plain statement of who spent how much at which merchant, whether it was approved or declined, and whether the money has actually moved. ## When each report is available and what it contains | Item | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Frequency | Once a day, generated in **full** (not incrementally) | | Timing | By default the previous day's file is generated on T+1; the exact run time is set on the scheduling platform | | File types | `authorisation` (authorization report) and `transaction` (transaction report), one of each per Enterprise | | How to retrieve | Call `GET /open-api/enterprise/v1/settlement-file-url` with `fileType` + `fileDate` (`yyyyMMdd`); it returns a download link valid for a fixed 120 seconds, and you can request a new one after it expires | > **The two files do different jobs**: the authorization report holds every authorization decision, including the declined ones (`approveFlag = D`), and is what you use to verify authorization outcomes and the release of holds; the transaction report is the authoritative record of money actually debited or credited. The two are joined through `outsId` (the outstanding ID) and `authIds`. See [Transaction lifecycle](../../basic-concepts/transaction-lifecycle). ## File format Both files are **plain text with `>`-delimited fields**, one record per line (not standard CSV). Column order is fixed and matches the tables below from top to bottom. An empty field appears as two consecutive delimiters. * **Amounts**: high-precision decimals (such as `0.100000000000000000`), not integers in minor units. * **Timestamps**: format `yyyy-MM-dd'T'HH:mm:ss+08:00`, time zone **UTC+8**. * **Card number (`pan`)**: only the **first six and last four digits**, masked in the middle so it is safe to store. ## Authorization report fields (fileType = �13�) > Column order matches the file. | Column | Field | Description | | ------ | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | `authId` | Unique authorization ID. Used to link to transaction flow, outstanding records and other downstream records | | 2 | `direction` | Transaction direction: `OUTGOING` (funds out, a purchase hold) / `INCOMING` (funds in, a refund release) | | 3 | `authType` | Authorization type: `NORMAL` / `FORCE_AUTH` / `EXPIRED_RELEASE` / `STATUS_DIFF_RELEASE`; see "Authorization type" below | | 4 | `outsId` | Outstanding ID. Links to the corresponding outstanding record and is the bridge between authorization and clearing | | 5 | `originalAuthId` | Original related authorization ID. Used to trace back in linked scenarios such as multiple refunds and incremental authorizations | | 6 | `enterpriseId` | Enterprise ID. Identifies the partner that initiated the authorization | | 7 | `customerId` | User ID. Identifies the cardholder the authorization belongs to | | 8 | `cardId` | Card ID. The card the transaction took place on | | 9 | `pan` | Card number, first six and last four digits only | | 10 | `approveFlag` | Authorization outcome: `A` = approved / `D` = declined | | 11 | `rejectReason` | Decline reason. Present only when `approveFlag = D` | | 12 | `approveDate` | Processing time, `yyyy-MM-dd'T'HH:mm:ss+08:00` | | 13 | `currency` | Settlement currency, ISO 3-digit currency code (numeric, such as `702`) | | 14 | `amount` | Settlement amount (high-precision decimal) | | 15 | `acquirerCurrency` | Requested currency. May differ from the settlement currency | | 16 | `acquirerAmount` | Requested amount, in the requested currency | | 17 | `cardAcceptorIdentification` | Merchant ID | | 18 | `cardAcceptorNameLocation` | Merchant details, name and address | | 19 | `transactionType` | Authorization transaction type: `R` = card purchase / `C` = ATM withdrawal / `Q` = inquiry / `P` = return or refund; see "Authorization transaction type" below | | 20 | `merchantType` | Merchant type (MCC), four digits | | 21 | `createTime` | When the authorization record was created; format as above | | 22 | `modifyTime` | When the authorization record was last modified; format as above | | 23 | `merchantCountryCode` | Merchant country code, three digits | ### Authorization type (`authType`) | Value | Name | Description | | --------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `NORMAL` | Normal authorization | The standard record produced by a real-time authorization callback from the channel; covers every real-time scenario, including purchases, incremental authorizations, reversals, refunds, cash withdrawals and inquiries | | `FORCE_AUTH` | Forced authorization | An authorization record the system creates by itself: clearing arrived with no matching authorization (an offline transaction, for example), or the cleared amount differs from the held amount and the difference must be booked | | `EXPIRED_RELEASE` | Expiry release | The authorization was never settled in time, and the channel uses the settlement file to instruct the release of the funds on hold | | `STATUS_DIFF_RELEASE` | Status mismatch release | A reconciliation correction for the case where the channel declined the authorization on timeout but the DCS side had approved it | ### Authorization transaction type (`transactionType`) | Value | Name | Description | | ----- | ---------------- | --------------------------------------------------- | | `R` | Card purchase | All card purchase transactions | | `C` | ATM withdrawal | ATM withdrawals and other cash advance transactions | | `Q` | Inquiry | Inquiry transactions, with no movement of funds | | `P` | Return or refund | Transfers or refunds credited back to the card | ## Transaction report fields (fileType = �62�) > Column order matches the file. | Column | Field | Description | | ------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | `transactionId` | Unique transaction ID. The unique number for each movement of funds | | 2 | `direction` | Transaction direction: `OUTGOING` (funds out) / `INCOMING` (funds in) | | 3 | `outsId` | Outstanding ID. Links to the corresponding outstanding record | | 4 | `authIds` | Related authorization IDs. Multiple authorizations are separated by commas, for example `1111,2222` | | 5 | `enterpriseId` | Enterprise ID. Identifies the partner the fund movement belongs to | | 6 | `customerId` | User ID. Identifies the cardholder the transaction belongs to | | 7 | `cardId` | Card ID | | 8 | `pan` | Card number, first six and last four digits only | | 9 | `category` | Transaction category: `RETAIL` / `CASH` / `CASH_FEES` / `PAYMENT` and others; see "Transaction category" below | | 10 | `currency` | Settlement currency, ISO 3-digit currency code | | 11 | `amount` | Settlement amount (high-precision decimal) | | 12 | `acquirerCurrency` | Requested currency | | 13 | `acquirerAmount` | Requested amount | | 14 | `cardAcceptorIdentification` | Merchant ID | | 15 | `cardAcceptorNameLocation` | Merchant details, name and address | | 16 | `multiClearInd` | Clearing indicator: `O` = ordinary single clearing / `P` = multi-part clearing, not the final part / `F` = multi-part clearing complete | | 17 | `merchantType` | Merchant type (MCC), four digits | | 18 | `createTime` | When the transaction record was created; format as above | | 19 | `modifyTime` | When the transaction record was last modified; format as above | | 20 | `merchantCountryCode` | Merchant country code, three digits | | 21 | `originalTransactionId` | Original transaction ID. For a refund-type record, the `transactionId` of the original transaction being refunded; empty for non-refund records | ### Transaction category (`category`) | Value | Name | Description | | ------------- | ------------------------ | ------------------------------------------------------------------------------------------------- | | `RETAIL` | Ordinary purchase | A standard card purchase transaction | | `RETAIL_FEES` | Purchase fee | Includes DCC fees, credit adjustments, annual card fees, replacement and reissue fees and similar | | `CASH` | Ordinary cash withdrawal | ATM withdrawals and other cash transactions | | `CASH_FEES` | Cash withdrawal fee | Includes cash withdrawal handling fees and similar | | `PAYMENT` | Return or refund | Returns, refunds and other incoming transactions | | `CHARGEBACK` | Dispute chargeback | A chargeback arising from a dispute raised by the cardholder | ## Points to watch when loading the files * **Treat the transaction report as the authority on money**: what a user was actually charged or refunded comes from the transaction report (`transaction`). The authorization report (`authorisation`) includes declined records and serves to verify authorization outcomes and the release of holds; never use it directly as evidence of a charge. * **Joining across files**: the same piece of business lines up across the two files through `outsId`, and a single transaction line can be traced back through `authIds` to one or more authorizations (for multi-part clearing, look at `multiClearInd = P/F`). * **Parse amounts as high-precision decimals**: parse as high-precision decimals rather than integers in minor units before storing, so you do not lose precision. * **Currencies are numeric codes**: `currency` and its siblings are ISO 4217 numeric codes (`840` = USD, `702` = SGD), so map by numeric code on load. ## Next steps * Not sure which clearing stage a record belongs to? Go back to [Transaction lifecycle](../../basic-concepts/transaction-lifecycle) and place the record on the authorization-to-clearing timeline. * Want to know how to fetch a file download link by date? See [Reconciliation overview](./overview).