> ## 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 Cycle & Calendar > Operational rules behind your settlement dates: the UTC+8 day cutoff, per-payment-method settlement agreements, the daily / weekly / half-monthly / monthly cycle types and how T+N is counted for each, business-day deferral against the merged holiday calendar, settlement batches, periods that net out negative, and the refund-reserve settlement that does not defer. [Merchant Settlement](/docs/en/essentials/merchant-settlement) describes the cycles we offer (T+1, T+10, weekly). This page covers the operational side: **which** transactions fall into a settlement, **which** calendar day the funds land on, and why a settlement date can pass with no money and no file. Report columns are defined in [Reconciliation reports](/docs/en/developer-docs/tools-and-references/references/reconciliation-reports). ## How is my settlement date calculated? 1. **Scope by transaction day.** Settlement preparation runs after each natural day closes and picks up transactions whose **success time** falls in the previous day, `00:00:00`–`23:59:59` **UTC+8**. 2. **Add the contracted cycle, then land on a business day.** For a T+N cycle the settlement date is the **first business day at or after T+N** — business days come from a holiday calendar, not a fixed weekday rule. Date fields on the Portal's Settlement Batch pages are labelled `(UTC+8)` for this reason. ## Why does my transaction-day total differ from yours by one day? This is the most common reconciliation gap, and three rules explain nearly all of it: | Rule | Effect on your figures | | - | - | | The day cutoff is **UTC+8**, not your local time zone | A transaction at 23:30 in a UTC-5 market belongs to the *next* UTC+8 day | | Scope uses **success time**, not creation time | An order created on day 1 and paid on day 2 settles with day 2 | | For refunds, success time is the **refund** success time | A refund of an old payment lands in the current period, not the original payment's period | ## Why do transactions on the same day settle on different dates? A settlement cycle is not a single merchant-level setting. Settlement agreements are configured per **MID + payment method** (and per contracted country), each carrying its own cycle type (day-based or week-based) and delay count **N**, its own settlement currency, and its own settlement target account. Two payment methods used on the same day — or the same method in two countries — can legitimately settle on different dates and in different currencies. ## What settlement cycles can my agreement be on? Five cycle types exist. Which one you are on, and the delay count **N** that goes with it, are set on your settlement agreement per MID and payment method — so different payment methods can be on different cycles. The cycle type decides two things at once: **which transactions are grouped together**, and **which date the delay is counted from**. | Cycle type | Transactions grouped together | Date N is counted from | | - | - | - | | `DAY` | One transaction day | That transaction day | | `WEEK` | Monday to Sunday | The Sunday closing that week | | `HALFMONTH` | The 1st to the 15th, or the 16th to the end of the month | The 15th, or the last day of the month | | `MONTH` | The whole calendar month | The last day of that month | | `MONTH_1X` | The whole calendar month | The last day of the **following** month | Read together with the rule above: **N is added to that date, and then the business-day rule moves the result out until it lands on a business day.** So T+N on a `DAY` cycle means N days after the transaction day itself; the same N on a `WEEK` cycle means N days after the week has closed. Two points that cause most of the confusion: * **`MONTH_1X` groups exactly the same transactions as `MONTH`.** The difference is only where the delay starts: the end of the following month rather than the end of the transaction month, so with the same N it pays out roughly a month later. * **On anything other than `DAY`, one settlement covers a range of days.** That is why the calendar's `Transaction Period` shows a range rather than a single date, and why your own daily totals will not line up one-for-one against a settlement. ## Which holidays affect my settlement date? Not one country's calendar. The business-day calculation uses the **merged, de-duplicated holiday calendar of all related countries** configured on your acquiring contract for that contracted country, weekends included. If any related country is closed, the date is not a settlement day and the settlement defers. Clicking a non-settlement day in the Portal calendar lists the reasons one by one as **Related Holidays** (*country + holiday name*), rather than a bare "Non-settlement Day" label. Only confirmed holidays are shown. ## How do I read and export the settlement calendar? The calendar's primary dimension is **Country/Region** — a single-select list of the countries covered by your active contracts, shown as ISO 3166-1 alpha-3 codes, first one selected by default. Everything follows that selection: * **Regions of Holidays** shows only the related countries of the selected country/region. * Transaction days and settlement dates (including deferred ones) are derived for that country/region only. * Rows show **Transaction Period**, **Scheduled Settlement Date** and **Actual Settlement Date**. * Export produces `settlement_calendar_[Region]_[YYYYMM].xlsx` with those same three columns, covering the selected country/region only. The calendar is a schedule view and offers no per-date file download — reconciliation reports are attached to the settlement batch instead. **Scheduled Settlement Date (Deferred)** exists because a scheduled date is computed when transactions are packed, and can still move afterwards — the holiday calendar changes, or a negative period rolls forward. It carries the deferred result, so both the original and the currently expected date stay visible. ## What exactly is one Settlement Batch? | Unit | Granularity | Meaning for you | | - | - | - | | **Settlement Batch** | merchant + scheduled settlement date + settlement currency | One settlement event: the funds paid to you plus its reconciliation reports | | **Settlement Entry** | the above + transaction currency | The accounting unit inside a batch | A batch deliberately spans countries, payment methods and order currencies. So if one settlement date carries **two settlement currencies**, you get **two batches**, each with its own settlement details and summary reports. The Settlement Batch list defaults to the last 30 days; a batch's detail page exposes its reconciliation reports and a transaction-level export. Inside a batch each transaction clears in a fixed four-step order — relevant if you recompute net amounts: fees and taxes billed in the **order currency** are deducted first, the remainder is converted to the **settlement currency**, fees and taxes billed in **other currencies** come next, and what remains is the **Net Settlement Amount**. ## A settlement date passed with no money and no file. Why? Usually the period's net amount was **negative** — refunds and chargebacks exceeded payments. Then: * No funds move on that date and **no settlement batch record is created**, which is also why no settlement report is generated by default. * The negative balance is **carried forward** and merged with following periods until the cumulative net turns positive; that settlement is the one that pays out. * We **do not draw on your reserve** to cover a negative period, and refunds are not funded from the reserve either. To tell "nothing to settle" apart from "file generation failed", ask support to enable header-only placeholder files on every scheduled date — it is a per-merchant configuration. ## Why did a settlement of refunds from my refund reserve arrangement ignore the holiday calendar? Because that kind of settlement is deliberately kept off the business-day rule. Refunds that were funded from your **refund reserve account** — see [Where Refund Money Comes From](/docs/en/support/refund-funding-source-faq) — are not netted into your ordinary settlements. They are cleared on their own, in their own settlement batch, and on their own date: | | Ordinary settlement | Settlement of refunds funded from your refund reserve | | - | - | - | | Date is derived from | Your settlement agreement's cycle type and delay count N | Your refund reserve arrangement's **end date plus a fixed number of calendar days**, as set out in the arrangement | | Deferred when a related country is closed | **Yes** | **No** — the calendar date stands, weekend or holiday | | Arrives in | Your regular settlement batch for that settlement currency | A settlement batch of its own | The reason for the exception is that this settlement closes out an arrangement rather than paying out a trading period. Its date is fixed by the arrangement you agreed to, so letting each related market's holidays push it around would make the close-out date unpredictable — the opposite of what the business-day rule is there to achieve for ordinary settlements. How to recognise one when you are reconciling: * It is a **separate settlement batch**, so a date can carry both an ordinary settlement and one of these. * Its transactions are refunds, not payments. * The `Comments` field on the settlement record, and in its settlement summary and detail files, is filled in to mark it as a refund reserve settlement. On an ordinary settlement that field is empty. What the reserve account itself is, and how holds and releases on it are counted, is in [Reserves](/docs/en/support/reserve-faq) — note that a **rolling reserve's** release date is a different calculation, counted in business days or calendar days according to your contract. ## An older settlement is still open. In what order do retries happen? A settlement that could not be booked because the unsettled account lacked balance is retried on later settlement runs, in a fixed order: **oldest settlement date first**, then within the same date **largest amount first**, until even the smallest outstanding settlement cannot be covered. Later dates are not processed ahead of an unfinished earlier one — which is why a Portal record can show a settlement date earlier than today and still be open. *** Still not matching? [Contact support](mailto:support@waffo.com) with the settlement batch id or the transaction day you are reconciling. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.