> ## 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. # Batch Payout Statuses & Funding > How to read a batch payout's status and its per-row statuses, why a batch can disappear from the list instead of showing as failed, why only some country templates are offered to you, and where the money for a payout is allowed to come from. This page covers how to **read** a batch payout — its statuses, its per-row results, and where its funding comes from. For the step-by-step of creating one in the Portal, and for withdrawals, see [Withdrawal & batch payout](/docs/en/support/withdrawal-and-batch-payout-faq). For the account the money moves through, see [Payout Wallet & coverage](/docs/en/support/payout-wallet-and-coverage-faq). For the single-payout API, see the [Payout FAQ](/docs/en/support/payout-faq). ## What are the limits on the batch file itself? | Limit | Value | | - | - | | File format | **`.xlsx` only** — the Portal upload accepts nothing else | | File size | Under **2 MB** | | File name | **100 characters** or fewer | | Rows per file | **1,000** maximum — a file with more is rejected and the batch is cancelled | | Files per upload | One | A CSV will not upload, whatever your spreadsheet tool suggests. Save as `.xlsx`. An empty file — a template with no data rows — is also rejected and cancels the batch, so a batch that vanishes immediately after upload is usually a file whose rows did not sit where the template expects them. ## What do Batch name and Batch description do? Does the payee see them? Neither is shown to any payee. Both are labels on your own batch record: | Field | Rules | Who sees it | | - | - | - | | **Batch name** | Required. Letters, digits, underscores and hyphens only — no spaces or other punctuation. Up to 100 characters. | Your Portal account | | **Batch description** | Optional. Up to 256 characters. | Your Portal account, including whoever confirms the batch | The description exists to tell a colleague approving the batch what it is for. What the payee actually sees on their statement is the per-row description from the file, not either of these. ## A row failed validation. Can I just send the good rows? No. Validation is all-or-nothing: **a single failed row cancels the whole batch**, and there is no way to submit the rows that passed. Fix the file and upload it again. You do get told exactly what was wrong with each row. After validation the batch record carries a **Checked** file — the same rows you uploaded, with a failure-reason column filled in on the rows that failed, carrying the error code and its message. Work from that file rather than guessing: the reasons are per-row and specific, covering field format problems, a row whose country or currencies differ from the rest of the batch, a payee account the receiving side rejected, and rows that fell past the available balance. ## What statuses can a batch have? Exactly two, from your side: | Batch status | Meaning | | - | - | | **In Progress** | The batch has been submitted and is being worked through — funds debited, rows routed, results being collected and accounted for. | | **Completed** | Every row in the batch has reached a final result, whether success or failure. | There is no third value. The filter on the batch list offers these two and nothing else. Two things follow from that, and both surprise people: * **In Progress covers several distinct internal stages.** A batch can sit in In Progress for a while and still be moving. Do not read a long In Progress as a stall. * **Completed means "all rows finalised", not "all rows succeeded".** A batch in which every row failed is still Completed. Always read the row statuses, never the batch status, to know whether money moved. ## Why can't I see a batch I know I created? Because a batch only appears on your list once it has been **submitted**. Before that, and if it never gets there, it is not in the merchant view at all — the batch list query itself filters to In Progress and Completed rather than merely hiding other values in the UI. The case to watch for: a batch that is abandoned before processing — for example because the available balance was insufficient at submission, or because it sat unsubmitted past its validity — **drops out of the list rather than appearing as failed or cancelled**. If a batch you expected has vanished, do not assume it silently went through. Re-check your balance at the time of submission and create the batch again. ## What statuses can an individual row have? Three, and these are the ones that tell you what actually happened: | Row status | Meaning | | - | - | | **In Progress** | The row has been accepted and is being processed. | | **Success** | Funds have been sent to the payee. | | **Failure** | The row did not go out. Its amount is returned to your settlement account; whether its fee is returned depends on your payout agreement. | Each row also carries a status timeline. The batch-level timeline is coarser — it shows the submission, the processing start and the completion — so use the row timeline when you need to explain a specific payee's delay. If a row shows **no status at all**, it is a row that never got as far as being routed — typically one that failed file validation. Treat a blank row status as a failure to resubmit, not as a pending payout. ## What does the batch status timeline show? Three points: **Submitted**, when the batch passed verification and was accepted — before any money moved; **In Progress**, when the funds were debited and processing began; and **Completed**, when every row finalised. Intermediate internal stages are not exposed as timeline nodes, so the timeline is a progress indicator rather than an audit trail. For reconciliation use the source, checked and result files attached to the batch record. ## Why are only some countries offered when I download a batch template? Because templates are issued **per contracted country**. The list you see is derived from your signed payout agreements: one template per country covered by an agreement that is currently active and inside its validity window. * No active agreement means **no templates at all** — an empty list here is a contracting question, not a bug. * The restriction is enforced on the **download**, not only in the UI. Asking for a country you are not contracted for is rejected rather than served. * The country you are contracted for also determines which columns the template asks for, which is why you cannot reuse one country's file for another. If a country you have signed for is listed but the download fails, that is worth raising with your Waffo contact — it means the agreement exists but the template file for it has not been provisioned. ## Is there a second confirmation step before a batch goes out? Yes — an explicit confirmation in the Portal after the preview. You see the available settlement balance, the total payout amount, the recipient total and the fee total, and you have to confirm before anything is debited. Insufficient balance rejects the submission at that point rather than part-processing the batch. That confirmation is an in-Portal step. Do not build a runbook that expects a verification code to arrive by email at this stage. ## I uploaded a batch but did not submit it. Can I cancel it? You do not need to. A batch that has been uploaded but not submitted is **closed automatically around four hours after it was created**, and closing it costs nothing — the debit happens at submission, so an unsubmitted batch has never touched your balance. Two consequences worth planning around: * **There is no cancel action**, because there is nothing to cancel. If you uploaded the wrong file, upload the right one as a new batch and leave the old one to lapse. * **Do not prepare a batch well ahead of when you intend to send it.** A batch reviewed on one day and submitted the next will not be there — it will have lapsed, and lapsed batches drop off the list rather than showing as cancelled, as described above. Upload and submit in one sitting. ## Do batch payouts send webhooks? No. The payout webhook is pushed only for payouts created through the API; a payout that originated as a row in a batch upload produces no notification, whatever its outcome. Track batch results from the batch record and its result file, or inquire each row's `payoutOrderId` through the payout API. See [Payout statuses, notifications & reports](/docs/en/support/payout-status-notifications-and-reports-faq). ## Where does the money for a payout come from? From your **acquiring settlement proceeds**. Every balance check and every debit on the batch payout path is taken against your **settlement account** for the relevant currency — the preview you approve reads that same balance, so what you see at preview is the account that will be charged. Two consequences: * Money credited to you anywhere other than the settlement account for the funding currency is not reachable by a payout batch. The payout path does not offer an account picker, and it will not fall back to another account if the settlement balance is short — it rejects the submission instead. * Payout is therefore downstream of settlement. If you need to increase payout capacity, the lever is settlement timing, not a separate top-up flow. See [Settlement cycle](/docs/en/support/settlement-cycle-faq) for what governs when proceeds land. ## Which of my settlement accounts can fund a payout? Can I choose? You cannot choose — it is determined by **currency**, and the currency comes from your payout agreement. * The payout agreement for a country records the funding currency alongside the payee currency. That funding currency is the sole selector of which settlement account is debited. * The funding currencies available when your agreement is set up are themselves limited to currencies in which you actually hold a settlement account, so an agreement cannot be written against an account you do not have. * Because the batch's funding currency is resolved per row from your agreements and then rolled up, **all rows in one batch must share the same funding currency, payee currency and country** — which is the underlying reason batch validation is all-or-nothing on those three fields. The practical planning rule: if you need to pay out in a corridor, you need both an agreement for that corridor **and** settlement proceeds accumulating in the funding currency that agreement names. Having the balance in a different currency does not help, and Waffo will not convert it for you as part of the payout. ## Why must every row in one batch share the same country and currencies? Because a batch is funded as a unit. The funding currency is resolved from your agreements per row and then rolled up to one value for the batch, and that single value selects the one settlement account to debit. A batch mixing corridors would need to debit more than one account, which the path does not do. That is why validation is **all-or-nothing** on country, funding currency and payee currency, and why a single bad row cancels the whole file rather than being dropped. Split multi-corridor payment runs into one batch per corridor and submit them separately; there is no partial submission. ## A batch has been In Progress for a long time. What should I check? In Progress spans several stages, so duration alone tells you nothing. Work through this instead: | Check | Why | | - | - | | Are any **rows** already final? | Rows finalise independently. A batch with successes already showing is moving, whatever the batch status says. | | Does the **row** timeline show movement? | Row timelines are finer-grained than the batch timeline and will show where a specific payee is held up. | | Has the **result file** appeared on the batch record? | It is produced as rows finalise and is the earliest reliable evidence of progress. | | Did your settlement balance cover the batch at submission? | An underfunded batch is rejected at submission rather than stalling — if you cannot find the batch at all, see the question above about vanished batches. | Do not resubmit the file to force progress. A second batch is a second debit and a second set of payouts, so raise a stuck batch with your Waffo contact rather than re-uploading it. ## How do I reconcile a batch once it is Completed? Work from the files on the batch record rather than from the screen: | File | Use | | - | - | | **Source** | The file you uploaded — your own reference for what you asked for. | | **Checked** | The post-validation view, showing what was accepted. | | **Result** | The per-row outcome, which is what you reconcile against your ledger. | Row-level failures return their amount to the settlement account they were debited from; check your Account History for the returned amounts rather than inferring them from the batch total. See [Balance & Account History](/docs/en/support/balance-and-account-history-faq) for how those entries are described. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.