> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Settlement Batches & Calendar > How transactions are grouped into settlement entries and batches, what the identifiers mean, what the settlement record's status timeline shows, what Balance History records and how to filter and export it, and how to read the settlement calendar's country dimension and holiday details. [Settlement Cycle & Calendar](/docs/en/support/settlement-cycle-faq) explains **which day** your money lands on. This page explains **how transactions are grouped into that payment**, what the resulting records and identifiers mean, and how to read the ledger and the calendar around them. Report file contents are in [Settlement File Specification](/docs/en/support/settlement-file-specification-faq). ## How are my transactions grouped into one settlement payment? Three levels of grouping, of which you only ever see the outer two: | Level | Grouped by | Do you see it? | | - | - | - | | **Pack** | Merchant + transaction success day + payment method + order currency + settlement currency | **No.** An internal preparation unit only | | **Settlement Entry** | Merchant + order currency + settlement currency | Yes — the accounting unit inside a batch | | **Settlement Batch** | Merchant + settlement currency + contracting entity + clearing type | Yes — one settlement event: the money paid to you plus its reports | Reading upward: transactions are first bundled per payment method and transaction day, those bundles are combined per order currency, and those are combined into a batch per settlement currency. Two dimensions of the batch key are easy to miss, and both mean you can receive **more than one settlement on the same date in the same currency**: * **Contracting entity.** If your transactions are acquired under more than one Waffo contracting entity, each settles in its own batch. * **Clearing type.** A settlement of refunds funded from a refund reserve arrangement is a separate clearing stream and **never shares a batch with an ordinary settlement** — it also ignores the holiday calendar. See [Settlement cycle & calendar](/docs/en/support/settlement-cycle-faq). That is why a batch deliberately spans payment methods, countries and order currencies. It is also why **one settlement date with two settlement currencies gives you two batches**, each with its own files — see [Settlement Reports & Exports](/docs/en/support/settlement-reports-faq). The Pack layer matters to you only as an explanation: because packing happens per payment method and transaction day, a single batch can legitimately cover **more than one transaction day**. Do not assume a one-to-one relationship between a settlement and a transaction day. ## What do the settlement identifiers mean? | Identifier | Shape | Meaning | | - | - | - | | Settlement Entry Id | `E` + merchant id + `yyyyMMdd` + sequence | One order-currency accounting unit inside a batch | | Settlement Batch Id | `S` + merchant id + `yyyyMMdd` + sequence | One settlement event, and the value in your settlement file names | The date inside the identifier is the date it was generated, not necessarily the date the funds moved — use the record's own date fields for that. The `S…` value is the one to quote to support: it is the key that resolves a settlement, its files and its ledger entry. ## What does a settlement record's status and timeline tell me? A settlement record carries a status, and its detail page carries the **full execution timeline** — which matters because a settlement can be attempted more than once: | Status | Meaning | | - | - | | `Created` | The settlement instruction has been generated | | `Unsettled` | An attempt could not be completed and it is waiting to be retried | | `Succeeded` | Booked | | `Failed` | Terminated without booking | The timeline records each event with its own timestamp — generation, each unsuccessful attempt, and the final outcome — so a record that ran, failed and later succeeded shows all three rather than only the last one. Records still in their initial state are not listed. Settlement records default to the **most recent 90 days** (UTC+8). A record can legitimately show a settlement date earlier than today and still be open; the retry order that produces this is described in [Settlement Cycle & Calendar](/docs/en/support/settlement-cycle-faq). ## What are Settlement Original Amount and Settlement Target Amount? | Field | Meaning | | - | - | | `Settlement Original Amount` | The net settled amount summed **in the order currency** | | `Settlement Target Amount` | The same money **after conversion** into the settlement currency | They are identical when your settlement agreement settles an order currency into itself. They differ when conversion is involved — and `Settlement Target Amount` is **empty until the conversion has completed**, which is a stage, not missing data. If you are reconciling and the target amount is blank, the settlement has been prepared but not yet converted. ## What does Balance History record, and which business types can I filter on? Balance History is the ledger of your **settlement account**, in every settlement currency you settle into. Six business types are filterable: | Business Type | What it covers | | - | - | | `SETTLEMENT` | Funds arriving from a settlement | | `WITHDRAWAL` | Withdrawal movements, including a withdrawal being unwound | | `ADJUSTMENT` | A manual adjustment | | `RESERVE_WITHHOLDING` | An amount withheld to a reserve | | `RESERVE_RELEASING` | A reserve hold being released | | `RESERVE_ADJUSTMENT` | The top-up that restores a drawn-down reserve from your settlement account | Two points that surprise people: * **Older rows can carry a type that is no longer produced.** An FX `Conversion` row from before conversion moved ahead of withdrawal still displays with its own label. The filter is a convenience, not a proof that a row type never existed. * **The Portal screen shows the settlement account.** Movements booked on the reserve account itself live on the separate **Reserve Account** page, with its own tabs for holds and releases and for adjustments; the API endpoint `/api/v1/account/history/inquiry` returns both accounts in one call — see [Settlement Account Structure](/docs/en/support/settlement-account-structure-faq). If your account has a refund reserve, that has its own history tab as well. ## Why don't I see FX conversion entries in Balance History any more? Because conversion now happens **before** funds reach your settlement account, not at withdrawal time. Consequences, all of them intentional: | Before | Now | | - | - | | Balances shown by transaction currency, pre-conversion | Balances shown **by settlement currency** | | Conversion appeared as its own movement in the ledger | Settlement arrives already converted, so there is nothing separate to record | | Conversion happened when you withdrew | Conversion is complete before you withdraw | | Multiple batches per order currency, some without a rate | **One batch per settlement currency**, with the forex rate shown per transaction | | Transaction report only | Settlement summary **and** settlement detail reports | If you are comparing against historical records, that is why old rows show a conversion movement and new ones do not. ## What columns does Balance History have, and how do I export it? | Column | Meaning | | - | - | | `Account No` | The account the movement was booked to | | `Account Type` | Which account it is | | `Business Id` | **The identifier of the thing that caused the movement** — a settlement batch id for a settlement, a withdrawal order id for a withdrawal | | `Business Type` | The category, as above | | `Direction` | `CREDIT` (in) or `DEBIT` (out) | | `Amount` / `Currency` | The movement | | `Balance` | The balance **immediately after** this movement | | `Datetime` | UTC+8 | | `Description` | What happened, e.g. `Withdrawal Submission`, `Withdrawal Fee`, `Withdrawal Cancelled` | `Business Id` is the join key back to the rest of the Portal — take a settlement batch id to Settlement Batch, a withdrawal order id to Withdrawal History. | Export | Rule | | - | - | | File name | `account_history_{merchant id}_{from}_{to}.csv` | | Timestamps in the name | `YYYYMMDDHHMMSS`, UTC+8 | | Maximum span | **31 days** — enforced in the Portal and again server-side | The export carries the same columns as the on-screen table, so a figure never changes meaning between the two. ## What are the default date windows? | View | Default | Order | | - | - | - | | Balance History | Most recent **30 days** | Newest first; same-timestamp rows by currency A–Z | | Settlement records | Most recent **90 days** | Most recent settlement first | | Settlement Batch | Most recent **30 days** | By actual settlement date, most recent first | All windows are UTC+8. Widen the filter explicitly if you are reconciling further back. ## Why is the settlement calendar organised by country rather than by currency? Because holidays are a property of countries, not currencies. The calendar's primary dimension is **Country/Region**, listing the countries covered by your active contracts as ISO 3166-1 alpha-3 codes, with the first one selected by default. Everything on the page follows that one selection: * **Regions of Holidays** shows only the related countries of the selected country/region, and cannot be changed independently. * Transaction days and settlement dates, deferrals included, are derived for that country/region only. * The export contains only the selected country/region. **The most frequently consulted regions are pinned at the front of the list**, ahead of alphabetical order. | Field | What it is | | - | - | | `Transaction Period` | The transaction days a settlement covers | | `Scheduled Settlement Date` | The date computed when the transactions were packed | | `Scheduled Settlement Date (Deferred)` | Where that date has since moved — a holiday calendar change, or a negative period rolling forward | | `Actual Settlement Date` | When it actually settled | Rows are ordered by the first transaction day of the period, then the last. Export produces `settlement_calendar_[Region]_[YYYYMM].xlsx`, with the selected country/region stated as a header row. There is no per-date file download on the calendar — reconciliation reports belong to the settlement batch. ## Why is a specific date not a settlement day? Click it. The calendar lists the reasons one by one as **Related Holidays**, in *country: holiday name* form — one line per related country that is closed that day. That replaces a bare "Non-settlement Day" label, so you can see exactly which country closed and why. Only **confirmed** holidays are shown. A candidate holiday still being verified does not defer your settlement and does not appear. The business-day calculation uses the **merged, de-duplicated holiday calendar of every related country** on your acquiring contract for that contracted country. If any of them is closed, the date is not a settlement day. ## Which countries' holidays affect me, and can that be changed? Two rules govern it: 1. **Consistency.** For one merchant and one contracted country, **all payment methods must carry the same set of related countries.** You cannot end up with one payment method deferring on a holiday and another not, within the same contracted country. This is what makes a single merged calendar meaningful. 2. **Configurability.** Which countries' holidays are taken into account **is configured per merchant**. A merchant with no exposure to a market has no reason to defer on that market's holidays, and a settlement route may require a market you do not sell in. If your deferrals do not match your business, raise it with your account manager — it is a contract configuration, not a fixed rule. The calendar always reflects the configuration actually in force for you, so the merged holidays it displays are the ones that will move your dates. *** Comparing a batch against your own records and something does not line up? [Contact support](mailto:support@waffo.com) with the settlement batch id — it resolves the settlement, its entries, its files and its ledger entry. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.