Checking your work
Checking against Revenue
Brickie's record of what you filed is Brickie's record. This asks Revenue directly what it actually holds, and compares.
Why this exists
Filings are signed in your browser and sent from there. What Brickie stores is what your browser reported back. That is almost always the truth, but “almost always” is not a good enough basis for a tax record.
A filing interrupted at the wrong moment, a response that never arrived, a browser closed mid-submission — each can leave a record here that looks complete and has nothing behind it at Revenue. Nothing in the normal flow would ever reveal that, because everything downstream trusts the stored record.
The question being asked
Not “what did Brickie file?” but “what does Revenue say it has?” — and then whether those two agree. A check that consults its own records proves nothing.
Running a check
On Check Revenue, run a check. Brickie asks Revenue for the documents in your ROS inbox and matches them against its own filings by the acknowledgement number Revenue issued at the time.
It needs your certificate unlocked, because it is a request to Revenue like any other. Each run is recorded so you have a history of when you last confirmed your records were real.
Reading the result
| Outcome | What it means | What to do |
|---|---|---|
| Confirmed | Brickie has a filing and Revenue holds the matching document. | Nothing. |
| Missing | Brickie believes it filed something Revenue has no document for. | Treat the filing as not made. Check ROS directly, and re-file if it genuinely is not there. |
| Unexpected | Revenue holds a document Brickie has no record of. | Usually filings made directly in ROS rather than through Brickie. Worth confirming that is what they are. |
| Unverifiable | A filing with no acknowledgement number to match on. | Normally a submission that failed before Revenue responded. Check whether it went through at all. |
Missing means missing
A payment shown as authorised in Brickie, with no corresponding document at Revenue, means the deduction was not actually authorised. If the payment has already been made, you are exposed on it — this is exactly the situation the 35% liability applies to. Deal with a missing result before your next return, not at the end of the year.
When to run one
- Before a return. The point at which a discrepancy becomes expensive rather than merely annoying.
- After anything went wrong while filing. A crash, a lost connection, a browser closed at the wrong moment.
- Periodically, without a reason. Monthly is plenty. A check that only runs when you already suspect something cannot tell you about the problem you did not suspect.
Checks are read-only. Running one files nothing, changes nothing at Revenue, and cannot make anything worse.