I've talked to a lot of Irish finance managers who think they're sorted on Enhanced Reporting Requirements. Most of them aren't sorted, and the reason isn't carelessness - it's that the guidance everyone's been given is partial.
The bit that gets covered well: ERR is live, you have to report mileage payments through ROS, the grace period ended on 1 January 2025. The bit that gets glossed over: what Revenue actually wants in the submission, what they don't want, and what they'll come looking for if you have to face an audit.
I've spent a fair amount of time picking through the Revenue FAQs and the Finance Act 2022 ERR provisions, plus what the actual ROS submission looks like in practice. Here's what I think most finance teams are missing.
What ERR actually is, in one paragraph
Enhanced Reporting Requirements is the regime that came in on 1 January 2024 under section 897C of the Finance Act 2022. It requires every Irish employer to report three categories of non-taxable employee remuneration to Revenue: small benefit exemption (the €1,000 voucher), remote working daily allowance (€3.20/day), and travel and subsistence (which is where mileage lives).
Reports go through Revenue Online Service (ROS) on or before the date of payment. The grace period that let employers backfill is gone. As of 1 January 2025, missing or late ERR submissions are part of routine PAYE compliance interventions.
The "we're reporting already" trap
Most finance managers I speak to say something like "our payroll provider handles ERR." That's usually true at the technical level - the payroll software files the JSON to ROS - but it doesn't mean the firm is compliant.
The ERR submission contains four things per mileage payment:
- The amount paid
- The date of payment
- The category (travel and subsistence)
- Whether the item is vouched or unvouched
That's it. No distance. No engine size. No project code. No driver name. No journey purpose. None of the data that actually proves the payment was correct.
That's the trap. ERR proves you reported the payment. It doesn't prove the payment was right. The two compliance gates are separate, and Revenue audits both.
What Revenue audits when they come in
If your business is selected for a PAYE compliance intervention, the inspector will reconcile your ERR submissions against your payroll, and then they'll ask to see the underlying records for a sample of payments. That's where the audit shifts from "did you file?" to "was the payment correct?"
For a mileage payment, the underlying records they'll expect to see are:
- The journey log - date, start, end, distance, purpose, vehicle
- The vehicle engine capacity and fuel type
- The cumulative year-to-date kilometres at the time of the trip
- The rate band applied and the calculation
- The approval - who approved, when
- Receipts for any additional expenses (tolls, parking) bundled into the claim
If you can't produce this for a sample of payments inside 21 days, the audit gets uncomfortable. Revenue can disallow the deduction, reclassify the payment as taxable, and look back across years.
Most spreadsheet-based mileage processes fail at the year-to-date kilometres line. The cumulative total either isn't tracked, or it's tracked in a separate sheet that doesn't reconcile to the payment record. A single missing trip can throw off every YTD calculation that follows it, and once the YTD is wrong, the rate band applied is wrong too. That's enough to fail the audit on records, even if the ERR submission was filed perfectly.
The deadlines
"On or before the date of payment" means exactly that. If you pay mileage as part of payroll, the ERR submission needs to be in ROS no later than the payroll payment date. If you pay mileage separately, each payment needs its own ERR submission on or before the payment date.
Late submissions are treated as compliance failures. Penalties are at the Revenue inspector's discretion under the standard PAYE compliance framework, and they can stack: a fixed penalty per late submission, plus interest, plus reclassification of the payment.
What good looks like
A finance team that's properly set up will have, for every mileage payment, a journey log that ties to a vehicle, that ties to an engine size, that ties to a year-to-date kilometre total, that ties to a rate band, that ties to a calculation, that ties to an approval, that ties to the payment in payroll, that ties to the ERR submission in ROS.
That chain is the audit defence. If you can produce it from one query, you're fine. If it lives across seven spreadsheets and the engineer's WhatsApp, you have a problem - and the problem is invisible until the inspector asks.
I'd start with one question: if Revenue asked you tomorrow for the journey records behind a single mileage payment from three months ago, how long would it take you to produce them? If the answer is more than ten minutes, the records side is the issue - ERR is just where the gap becomes visible.
The bottom line
Filing ERR isn't the same as being compliant on mileage. The submission proves you reported. The records prove the payment was correct. Revenue audits both, and a clean ERR file with a messy records system invites scrutiny of the records side - which is the side your spreadsheet won't survive.
If you're not sure your records would survive a single-payment audit query, that's the project to fix, not the ERR side. The ERR submission is the easy bit. The audit trail behind it is what saves you when the letter arrives. If your records live across forty-seven Excel tabs and an engineer's WhatsApp, the audit trail isn't really there.
Want to see what an audit-ready mileage process looks like?
Book a 20-minute demo and I'll walk you through what every mileage payment looks like in OdoHub - from the journey log to the year-to-date band split to the approval to the payroll export to the ERR submission. One chain that produces a defensible record from a single query.
Last updated: 28 April 2026.
