Uploading a settlement file
Where to get the file, what the Payout Auditor does with it, and why re-uploading one you have already sent reads as an empty file.
Before you start
Only an account owner can upload a settlement. A manager's upload is refused after it is sent, and the message says the upload failed rather than naming the permission — so if you are signed in as a manager and an upload will not take, check who you are signed in as before you go looking for a fault in the file.
Getting the file
Every delivery partner publishes a settlement statement for each payout cycle in their own merchant dashboard, and every one of them offers it as a CSV. Download it there and keep it as it came — do not open it in a spreadsheet, fix a column and save it again. The audit reads the statement itself, and an edited copy is no longer the partner's word about what they paid you.
Uploading it
Drop the file onto the Payout Auditor, or click to choose it. There is nothing to select first: the platform is worked out from the file's own column headers, so a Swiggy statement and a Zomato statement are dropped in exactly the same place.
One file at a time works on every plan, forever. Sending a folder of them in one go is a paid capability; when it is not on your plan you are told so rather than being left with a dead button, and single uploads keep working.
What happens to it
The file is read row by row and every figure is converted to exact whole paise — no rounding, no decimals that drift. Each row becomes a settlement line, and the line is checked against the payout it should have produced. Anything that comes up short becomes a variance, and the classes that can be attributed to an exact order become draft claims for you to review.
Dates are the messiest part of these files and are handled for you. Day-first, month-name, two-digit years, ISO with a time on the end — all of them are normalised to one form, so a statement exported from a spreadsheet reconciles the same way as one downloaded raw.
The statement itself is stored alongside the figures it produced. That is what lets a claim, months later, still point at the row it came from.
When the file cannot be read
If a column the audit needs is missing, the upload is refused loudly and nothing at all is recorded — no half-imported statement, no partial figures. The usual cause is a partner changing their export layout, which they do without notice. Send us the file from the Support page and the layout gets added.
The same is true of a file that reads cleanly but has no settlement rows in it: it is refused rather than accepted as an empty statement.
Uploading the same file twice
This is worth reading even if nothing looks wrong. A statement is fingerprinted when it arrives, and an identical file sent a second time is deliberately ignored — otherwise every figure on the screen would double, and a payout you were owed once would look like a payout you were owed twice.
Today that protection reads badly. A repeat upload reports success with a count of zero lines, which looks exactly like an empty or broken file. It is not. Zero lines on a file you recognise means "this statement is already on record", and the figures you can see already include it.
The tell is the files-parsed count on the same screen: if it did not move, the statement was already there. When you send a folder at once, duplicates are counted and reported separately from failures, which is clearer — that clarity has simply not reached the single-file message yet.
Sample data
A brand-new account carries a few sample rows so the screen is not blank on the first visit. They are labelled, they are excluded from the totals above the tables, and they are removed from the business profile in the back office when you are ready to see only your own money.