Prepare the Irish RTD (Return of Trading Details) From Invoices

The Return of Trading Details (RTD) is an annual VAT return that every VAT-registered business in Ireland must file. It carries no liability to pay. Unlike the VAT3, which works out what you owe or reclaim, the RTD is a statistics return: it tells Revenue the net value of everything you bought and sold over the year, broken down by VAT rate. You file it online through ROS, and it is due within 23 days of the end of your accounting year. There is no ROS-Offline file for it, so it has to be completed live in the system.

Every figure on the return is VAT-exclusive, that is, the net amount before VAT. The RTD reports the net value of all your sales and all your purchases for the year, broken down by VAT rate and split between stock for resale (Section 3) and other deductible goods and services (Section 4). It is made available alongside the final VAT3 of your accounting period, and the figures on it have to reconcile back to the VAT3 returns you already filed during that period.

The obligation is not optional or marginal. According to Grant Thornton's VAT Return of Trading Details factsheet, every VAT-registered trader in Ireland must file an annual Return of Trading Details within 23 days of the end of its accounting year, summarising the VAT-exclusive value of sales and purchases broken down by VAT rate.

The hard part is rarely the form itself, which is short. It is arriving at the numbers that go in it. Revenue's own guidance assumes you already hold those figures; the software vendors assume your year is already posted in their system. If you are working from a year of invoices and receipts and a spreadsheet, that leaves a gap. The rest of this guide closes it, in the order the job actually runs: build the net-by-rate figures from your invoices, split your purchases between Section 3 and Section 4, reconcile the result to the VAT3s you have already filed, and understand what is at stake if the return is late or wrong.

The RTD and the VAT3: Two Halves of One Compliance Cycle

The VAT3 and the RTD are easy to conflate because both come out of the same pile of invoices. They do different jobs. The VAT3 is the periodic return, usually bi-monthly, that calculates a number you act on: the VAT you owe Revenue for the period, or the refund you are due. It is a liability calculation, and you file it six times a year for most traders. The RTD is annual, and it calculates nothing you pay. It is a statistical breakdown of all your sales and all your purchases for the full year, classified by VAT rate and, on the purchases side, split between stock for resale and other deductible goods and services.

So why does Revenue ask for it at all, on top of six VAT3s? Because the RTD is how Revenue cross-checks the year. The VAT3s tell Revenue what you declared as your liability period by period; the RTD tells Revenue the underlying trading those liabilities should have come from. When the two line up, the year hangs together. When they do not, the RTD is the return that flags it. That is the whole reason the figures must reconcile to the VAT3s, and it is why a mismatch draws a query rather than being quietly absorbed.

Treat them as two halves of one annual cycle rather than two separate chores. The same source documents, a year of sales and purchase invoices, feed both returns; the RTD just aggregates them differently, by rate and category across the whole year instead of by net liability per period. If you handle the periodic side as well, the mechanics of preparing the bi-monthly VAT3 return from supplier invoices follow the same document-first logic, and the figures you produce there are the ones the RTD has to agree with at year-end.

Building Your RTD Figures From a Year of Invoices

This is the part no incumbent helps with, and it is the part that takes the time. The RTD boxes want net totals by VAT rate, for both sales and purchases, across the whole accounting year. If your year is not sitting posted in accounting software, you build those totals from the documents themselves. The workflow is the same whether you are a bookkeeper with a shoebox or a practitioner with a client's folder of PDFs:

1. Gather every sales and purchase invoice for the accounting year, plus the receipts that carry VAT.
2. For each one, read off the net (VAT-exclusive) amount and the VAT rate that was applied.
3. Sort each net amount into its rate band.
4. Sum the net per band. Those sums are the figures that map onto the RTD's sales and purchases boxes.

The rate bands the RTD breaks figures into are the standard 23%, the reduced 13.5%, the second reduced 9%, the zero rate, and exempt supplies. The return has to reflect whatever rate actually applied at the time of each supply, including a rate that has since changed. The 9% band is the live example of why this matters: the 9% rate that applied to hospitality and food services reverted to 13.5% during 2023, so an accounting year that straddles that change will hold catering or food supplies at both rates. On the RTD each one belongs in the band that was in force when the supply happened, not the band that applies today. Getting this right is mostly a matter of reading the invoice rather than assuming a rate, which is why working from source documents tends to be more reliable than reclassifying after the fact.

Two practical wrinkles come up constantly. First, a lot of purchases, especially till receipts and smaller buys, show only the gross total and the VAT rate, not a clean net figure. You back the net out of the gross before it can go in a band; the mechanics of how to calculate net and VAT from gross invoice totals are worth getting right once and reusing, because an error there flows straight into the return. Second, once every document carries a net figure and a rate, you are summing across potentially hundreds of them. The approach for total net spend by rate across a batch of invoices is the same summation the RTD needs, just pointed at the year rather than a single period. Throughout, the field you are reading off each document, the net, the VAT rate, the supply type, is governed by the Irish VAT invoice requirements and rates that a compliant invoice should already show.

The whole method runs on nothing more than the invoices and a spreadsheet, which is precisely what makes it work for anyone trying to complete the RTD without accounting software. The slow step is turning a year of mixed-format invoices and receipts into that clean net-by-rate table in the first place. That is the extract-and-classify job sitting in front of the RTD, and it is the one our tool was built for: you upload the batch of invoices, describe the columns you need in plain language, for example the net amount, the VAT rate, and whether each purchase is stock for resale, and the result is a structured spreadsheet you can total by band. It is the same step as doing it by hand, which is to extract and classify a year of invoices into a structured spreadsheet, only the reading and typing are done for you. The classification logic and the reconciliation that follow are unchanged; the figures still have to be yours and still have to be right.

Section 3 vs Section 4: Splitting Purchases for Resale

The sales side of the RTD is a straight net-by-rate breakdown. The purchases side asks one more thing, and it is where filers stall: every purchase has to be assigned to one of two buckets. Section 3 is stock for resale, that is, goods and materials you bought to sell on, or to build into something you sell. Section 4 is everything else deductible, the other goods and services the business buys to run itself: overheads, equipment, professional fees, software, consumables, utilities.

The working rule, applied as you classify rather than afterwards, is to ask of each purchase invoice: was this bought to be sold on (in its current form or worked into a product), or was it bought to operate the business? A wholesaler's pallet of goods, a retailer's stock, a manufacturer's raw materials go to Section 3. The same retailer's till rolls, accountancy fees, van lease, and electricity go to Section 4. The borderline calls are the ones worth slowing down for: a piece of equipment bought to run the business is Section 4, even though it is a sizeable purchase, while the goods that equipment helps sell are Section 3. The test is the purpose of the buy, not its size or its supplier.

The split is not cosmetic. The Section 4 figure is the one that interacts with your deductibility position. A business that can reclaim all of its input VAT treats Section 4 as straightforwardly deductible, but a business with partly exempt activities, which cannot reclaim every euro of VAT it incurs, sees its deduction rate bear on the Section 4 numbers. If that is you, the Section 3 versus Section 4 line is doing real work, and getting purchases into the wrong bucket distorts it.

One thing that catches people out: the resale-versus-not split does not replace the rate breakdown, it sits on top of it. Purchases still have to be broken down by VAT rate within each section, so you are classifying in two dimensions at once, by rate and by section. In practice that means a purchase invoice carries two tags as you sort it, its VAT rate and its Section 3 or Section 4 home, and your year-end table needs a cell for each combination.

When the RTD Doesn't Balance: Reconciling to Your VAT3s

The RTD has to tie back to the sales and purchases you declared across the year's VAT3 returns, and Revenue does look at the figures field by field. That does not mean the two have to match to the cent on first pass. Some differences are legitimate and expected; the point is that every difference should be explainable, and the totals should reconcile to the periodic returns once you account for the known causes. A return that does not reconcile, and that you cannot explain, is the one that invites a query.

The classic reason an otherwise correct RTD will not balance is EU and import transactions that made it onto the VAT3 but got dropped from the RTD. Intra-EU acquisitions, EU services, and imports are accounted for on the VAT3 under reverse charge or postponed accounting, and it is easy to treat them as a VAT3-only concern. On the RTD they have to appear too, and by design they can show up in more than one place: an intra-EU acquisition of goods is recorded both as a purchase and as a corresponding self-supply, so a single transaction touches the return twice. That is exactly the kind of entry a software RTD report or a half-built spreadsheet leaves out, because nothing about the purchase invoice itself flags that it carries this treatment. If your imports run through postponed VAT accounting on imports after Brexit, trace each one to where its figures have to land on the RTD, not just to the VAT3 box where you first dealt with it.

If your intra-EU goods movements are large enough, the same purchase and sales invoices that feed the RTD also feed a separate obligation, and it is worth knowing that building the Irish Intrastat RPF CSV from invoices draws on the same source documents. Keeping the EU transactions visible across all three returns is what stops them falling through the gap on the one you happen to be working on.

Beyond the EU trap, the other legitimate causes of a non-reconciling RTD are worth knowing so you can diagnose rather than force the numbers:

• Mis-rated supplies and mis-set tax codes, where a supply was put in the wrong band on one return but not the other.
• Capital Goods Scheme adjustments, which move VAT over time and will not sit neatly against a single period's trading.
• Section 4 partial deductibility, where a restricted deduction rate makes the reclaimed VAT diverge from the headline net purchases.
• Timing and bad-debt differences, including bad-debt relief claimed in one period that has no matching trading entry.
• Manual journals posted directly in accounting software, which a built-in RTD report often does not pick up.

The practical method is to total your RTD figures by rate and set them against the summed VAT3 boxes for the year, then work each variance back to one of the causes above. Investigate the difference; do not paper over it. A reconciliation you can explain line by line is worth more than a return that balances because you nudged it.

What Happens If the RTD Is Late, Missing, or Wrong

Because the RTD carries no payment, it is easy to file it late, file it carelessly, or not file it at all. The consequences do not respect that logic. An outstanding or mismatched RTD can hold up your VAT refunds, and an unresolved compliance record can affect refunds under other tax heads too, not just VAT. It can also delay or block your tax clearance. For a business that needs clearance to tender for public contracts, draw down grants, or get paid by certain customers, a stalled clearance over an unfiled statistics return is a real operational problem.

Subcontractors have a specific exposure. A compliance record marked by an outstanding RTD can feed into your Relevant Contracts Tax status, and a worsened compliance position can push you to a higher RCT deduction rate, meaning principal contractors withhold tax from your payments at a steeper rate. A return with no tax due can therefore cost you cash flow elsewhere.

All of this comes back to reconciliation. The return that does not tie back is the one that triggers the query, and the query is what holds up the refund or the clearance. The build-and-reconcile discipline is not box-ticking; it is what keeps the money moving. The RTD is a statistics return with real teeth, and the surest way to keep it from becoming a problem is to prepare it from accurate, rate-classified, correctly-sectioned invoice figures in the first place.