Many money transfer businesses still build their regulatory transaction reports the same way: export transfers to a spreadsheet, delete the columns the regulator does not want, fix the formats by hand, and hope nothing slipped through. The export is quick. The checking is slow, and the part nobody can easily answer is the one that matters most: did every reportable transfer make it into the file?
This guide is for compliance heads, MLROs and finance leads who lodge transaction reports with a regulator. It covers what makes a transfer reportable, how to produce the file from your own records, and how to prove it is complete. The approach applies on any platform; where RemitSo handles a step, we say so. Reporting rules differ by country, so confirm the details with your regulator or adviser.
Why spreadsheet reporting goes wrong
- Filters drop transfers. A filter on status or date that made sense last month quietly excludes a transfer that should have been in this one.
- Edits break the link to the source. Once a figure is typed over in a spreadsheet, nobody can show which transfer it came from.
- Operational detail leaks. An export built for operations carries internal notes, staff names and fields the regulator never asked for.
- Every run is rebuilt. The person who knew which columns to delete is on holiday the week the report is due.
Each of these is a reporting risk, not just an inconvenience. A late, incomplete or inaccurate report is a breach in most regimes.
Decide, in writing, what makes a transfer reportable
Before you build any report, write down the rule that puts a transfer in or out. Most disputes about completeness are really disputes about scope. Typical questions:
| Situation | Question to answer |
|---|---|
| The customer started a transfer but never paid | Was an instruction ever accepted? Usually out |
| Paid, then cancelled before payout | Does your regime count the instruction or only the payout? |
| Paid and accepted, payout later failed or was reversed | Was the instruction accepted? If your rule is about the instruction, it stays in |
| Paid on the last day of the period, paid out the next day | Which date decides the period: payment, acceptance or payout? |
Agree the answers with your regulator's guidance, write them into your procedure, and make the platform apply them, so the rule is the same every run regardless of who presses the button.
Rule of thumb: if two people could build this month's report and get different row counts, your scope rule lives in someone's head rather than in your system.
Produce the file from the transaction record itself
The strongest report is produced from the same record your platform uses to move money, not from an export someone has reshaped.
- Use the regulator's format directly: the fields, order and file type the regulator specifies, produced by the platform rather than by hand.
- Carry only what the regulator wants: leave out internal notes and operational fields that the transaction screens show.
- Preview before you download: read the rows on screen first, so obvious problems show up before a file exists.
- Save the report shape: name the configuration once, then choose only the period each run.
- Restrict who can run it: report production should be a permission, and every run recorded.
Check every run against the transfers in scope
A report can be perfectly formatted and still incomplete. Before lodging, compare the file with the transfers that should be in it:
- Count the transfers your scope rule says are reportable for the period.
- Count the rows in the file.
- If they differ, list the transfers in scope that are not in the file, and the reason for each.
Most differences have a mundane cause, such as a transfer with a missing field the format requires. The point is to find them before the regulator does, fix the data, and run the report again.
Key point: completeness is a separate check from formatting. A file the regulator's system accepts can still be missing transfers.
Scenario: a month-end report with one missing transfer
The figures are illustrative. At month end the compliance officer runs the saved report for the month. The on-screen check shows 1,204 transfers in scope and 1,203 rows in the file. The missing transfer was paid and accepted on the last afternoon of the month, and its payout was reversed two days later. Under the operator's rule, an accepted instruction stays reportable even if the payout later fails, so it belongs in the file.
The cause turns out to be a recipient record missing a field the format requires. The officer corrects the recipient's details, runs the report again, the counts match, and the file is lodged on time. Without the check, the report would have been accepted by the regulator's system and been short by one transfer.
Keep the evidence an examiner will ask for
- Your scope rule and when it last changed.
- Each run: who ran it, for which period, and the completeness result.
- Each difference: the transfer, the cause and how it was resolved.
- What was lodged and when.
Doing it with RemitSo
Since release 2026.09.1, RemitSo produces regulatory reports from the platform's own transaction record. Your team still owns the scope decisions, reviews each run and lodges the report.
- Regulator-ready formats, starting with Australia's IFTI-E (international funds transfer instruction) report, in Excel or CSV.
- Only what the regulator wants: the file carries the regulator's fields and none of the operational detail the transaction screens show.
- A clear reportability rule: money received and instruction accepted. A transfer stays in even if its payout later failed or was reversed; cancelled and awaiting-payment transfers are left out.
- Preview on screen, then download; save a report shape by name and choose the period each run.
- Every run checked against the transfers in scope, so you can see whether anything was left out before you lodge.
- A "Regulatory report ready" alert to the people subscribed to it, roles for every page and action, and a searchable audit log of who changed what, and when.
See the admin features, read the release notes, or book a demo to see a report run on example data.
Frequently asked questions
Should a transfer whose payout failed still be reported?
It depends on your regime's rule. Where the report is about instructions accepted, yes: the instruction happened even if the payout later failed. Write your rule down and apply it the same way every run.
Is an export plus a spreadsheet acceptable?
It can be, but it is where most reporting errors come from: filters that drop rows, figures typed over, and fields the regulator never asked for. A report produced from the transaction record, with a completeness check, removes those risks.
Which report formats does RemitSo produce?
Australia's IFTI-E report is the first. Ask RemitSo about the formats your regulators require.
How do we prove a report was complete?
Keep the completeness check for each run: transfers in scope, rows in the file, and any difference with its cause and resolution.