Prepare the Irish Intrastat RPF CSV from Invoices

Irish traders whose annual intra-EU arrivals or dispatches exceed €750,000 must file detailed monthly Intrastat returns to Revenue through the Return Preparation Facility (RPF), which has replaced the older ROS Offline application. Returns are due by the 23rd of the month following the reference period. Revenue ships two separate hardcoded CSV templates, one for arrivals and one for dispatches, and supporting records must be retained for two years.

The €750,000 threshold applies to both flows independently and has been in force since 1 January 2025, replacing the older split (€500,000 for arrivals, €635,000 for dispatches) that still appears on several compliance-vendor explainers. A trader sitting below the threshold on both flows has only the VIES summary obligation; the detailed monthly Intrastat return is reserved for the larger movers. Revenue's VIMA Intrastat thresholds and filing guidance is the current source for the figure.

RPF is now where arrivals and dispatches are prepared. Anyone whose last return ran through the ROS Offline application is on the wrong tool. RPF treats Revenue's CSV templates as hardcoded: column order and headers cannot be edited before upload, and a CSV with the wrong shape is rejected at the door. That single constraint sets the rest of this article up, because it means the spreadsheet a finance team actually builds in Excel sits one layer upstream of the RPF CSV rather than in place of it.

This piece is the practical bridge between an invoice stack and that upload. It is not a walkthrough of the RPF screens, which Revenue's own PDFs cover well, and it is not a general explainer on what Intrastat is. The job to prepare the Intrastat RPF CSV from invoices in Ireland breaks down into a working paper organised around three buckets of fields: those that can be lifted straight off invoices, those that need enrichment from product master or shipment data, and those that need a human classification call before the line is allowed through. The sections below take each in turn, then close on the operational tail end — the mapping into the Revenue template, nil returns, and what to standardise so each subsequent month is a refresh rather than a rebuild.

How the working paper sits between the invoice stack and the RPF CSV

The working paper is the spreadsheet a finance team actually builds in Excel before opening RPF. It is the place where invoice-derived figures, product-master enrichment, and human review come together; the Revenue CSV template is what the working paper feeds into at the end. RPF will not accept anything other than the template it ships, in the columns it ships, so trying to compress the entire monthly preparation into the template itself is a recipe for losing the audit trail and the working space the team needs.

Row structure is line-level. One row per goods line — a single supplier invoice with three different products at three different commodity codes becomes three rows on the working paper, and a single dispatch shipment covering five products becomes five rows. Intrastat does not aggregate by invoice or by partner; the statistic Revenue collects is the goods movement, and the goods movement is per line. Building the working paper at any coarser grain forces a re-explosion later.

Arrivals and dispatches live in separate workbooks. They use different Revenue CSV templates, they answer different declarant questions, and the lines do not cross over (a credit on a dispatch never becomes an arrival). The cleanest pattern is one workbook per flow per reference period — arrivals_2026-04.xlsx and dispatches_2026-04.xlsx, or the equivalent in whatever naming the team already uses. Mixing the flows on a single sheet creates errors that surface only at RPF validation, by which point the trail back to the source invoice is harder to follow.

Build the working-paper columns in the same order as the Revenue CSV template for that flow. If the working paper mirrors the template column order, the last step is a paste; if it does not, the last step is a manual remap every month, with all the transcription error that brings. Keep the template open while the working-paper header row is set up the first time, and the column order is a problem the team solves once.

Then add the reference columns the team needs internally but that do not ship to Revenue. The minimum useful set is the source invoice number, the invoice line number on that source invoice, the supplier or customer name in human-readable form, the internal SKU, a free-text notes column for anything the line cannot explain on its own, and a review-status flag for lines that need a second pair of eyes before the upload. These columns are how the team audits its own working paper, answers a Revenue query against a specific row six months later, and routes Bucket 3 lines without losing track of them. Drop them before mapping into the Revenue CSV; keep them on the archived working paper.

The working paper is only as good as the invoices feeding it. Where supplier and customer invoices arrive missing fields the Bucket 1 columns rely on — VAT numbers, line-level net values, dates that match the goods movement — the working paper degrades and Bucket 3 inherits the backlog. Ireland's mandatory VAT invoice fields sets the baseline a compliant invoice should carry; chasing a supplier on the missing fields is cheaper than re-handling the line every month.

Bucket 1: fields you can lift straight from invoices

Most of the columns the working paper needs in the early-month push come straight off the supplier and customer invoice stack. The trick is knowing exactly which figure on the invoice maps to which Intrastat field, and where the invoice signal stops being authoritative.

Invoice value excluding VAT and excise. Intrastat records goods value on the invoice basis, not the VAT-inclusive figure. On a supplier invoice that itemises VAT separately, the net-of-VAT line value is what goes on the working paper for that line. On a zero-rated intra-community supply — which most arrivals from EU vendors will be — the invoice net is already the right figure because no VAT was charged. Excise should be stripped where it appears as a separately identifiable amount on the invoice; embedded excise that the supplier does not itemise stays in the reported value by default.

Currency and currency conversion. Revenue requires the invoice value to be reported in euro. Where the source invoice is in another currency, the working paper needs the converted value, the conversion rate, and the rate date held alongside it. The defensible choices are the Revenue monthly rate for the reference period or the ECB reference rate for a consistent date within the period, applied the same way every month. The point is reproducibility: if Revenue queries a line six months later, the working paper should be able to produce the rate and the source on demand rather than asking the team to reconstruct it.

Partner VAT number. Dispatches carry a hard requirement: the customer's EU VAT number is mandatory on the dispatch return wherever the customer is VAT-registered in another Member State. Hold the number on the working paper exactly as it appears on the invoice, including the two-letter country prefix (FR, DE, IT, and so on), because RPF validates the prefix as part of the field. Arrivals are slightly different — the arrivals return keys on the reporting trader's own VAT registration rather than the supplier's — but the supplier VAT number is worth capturing on the working paper anyway for audit traceability and for cross-checking against the VAT3. Run a VIES check on the customer VAT number before upload: a number that has lapsed or never existed will fail the dispatch line in RPF, and Revenue's online VIES tool returns the answer in seconds. Where the dispatch line concerns a B2B customer, this is closely tied to intra-community acquisition VAT treatment on EU supplier invoices on the mirror side, because the same VAT-number-bearing relationship sits behind both returns.

Invoice date as the reference-period anchor. The reference period is the calendar month in which the goods movement occurred. For most trading patterns that ties cleanly to the invoice date or the receipt-of-goods date and not to the payment date. The reflex to follow the VAT tax point is wrong if it pulls a line into a different month than the physical movement; Intrastat is a goods-movement statistic, not a VAT timing statistic, and the two diverge for things like advance invoices and held stock.

Product descriptions and unit quantities. Neither field is shipped to Revenue on the CSV — Revenue does not want free-text descriptions — but both are load-bearing for the next bucket. Product descriptions feed the 8-digit commodity code lookup, and unit quantities feed the supplementary unit calculation. A working paper that strips the line description down to a bare SKU on import makes the Bucket 2 work materially harder, because there is nothing left to reconcile the SKU lookup against when something looks wrong.

Country signals visible on the invoice. The "from" country on a supplier invoice and the "to" country on a customer invoice are useful sanity checks for the country of consignment on arrivals or the dispatch country on dispatches. They are not the same field as country of origin, which is the manufacturer country of the goods themselves and which the next section covers. Treat the invoice country signal as a confirmation, not as the source of truth where the goods were originally produced.

Building those columns by hand for any sustained volume of invoices is slow and prone to transcription error, particularly on partner VAT numbers and net values where one wrong character fails the line at RPF. This is where AI-powered invoice data extraction for Irish finance teams earns its place inside the working paper, converting batches of up to 6,000 supplier and customer invoices into a structured spreadsheet containing the exact Bucket 1 columns the working paper needs: invoice number, invoice date, partner VAT number, net-of-VAT line value, currency, line descriptions, quantities. The output can be invoice-level or line-item-level depending on how the working paper is structured, and the prompt is the configuration — a single description of the columns the team wants and the formatting rules (date format, decimal precision, native Excel typing) is reapplied across every invoice in the batch, so the output is consistent whether the batch is ten invoices or ten thousand.

What the tool does not do is choose Intrastat commodity codes, country of origin, terms of delivery, or nature of transaction. Those depend on product master data and shipment paperwork rather than the invoice itself, which is the explicit lead-in to the next two buckets.

Bucket 2: fields that need product master or shipment enrichment

The remaining columns on Revenue's template are not on the invoice and never will be. They live on the product master, the packing list, the despatch advice, or the purchase order, and the working paper enriches Bucket 1 from those sources rather than trying to infer them from the invoice line.

8-digit commodity code (Combined Nomenclature). The CN code is a property of the product, not of the transaction. Keep a lookup table keyed on internal SKU that returns the current 8-digit code, and join Bucket 1's SKU column against it to populate the commodity-code column on the working paper. Refresh the lookup at least annually because the CN list changes; a code that was valid last year but has since been retired or split will either fail RPF validation or, worse, pass while reporting the line under a category that no longer fits. Where a product has no assigned code at all, the line moves to Bucket 3 for classification review and does not get a guess.

This is also where the instinct to pull the commodity code straight from the invoice trips teams up. The product description on the invoice is a clue for the classifier, not the answer. Even where suppliers print a code on the invoice itself, it is their classification under their own jurisdiction's rules, and it should be reconciled against the trader's own CN lookup before it goes on the return. The working paper's product description column (carried in from Bucket 1) earns its place here, as the audit field a reviewer reads to sanity-check the lookup output.

Country of origin. This is the manufacturer country of the goods, not the supplier's invoicing country and not the country of consignment. A French supplier shipping Italian-manufactured goods produces a French country of consignment on the arrivals return and an Italian country of origin on the same row. Because origin is a property of the product, it belongs on the product master alongside the CN code, and the same SKU lookup that feeds the commodity code should feed the country of origin. Treating origin as an invoice attribute creates a Bucket 3 review queue that is entirely avoidable.

Net mass in kilograms. Mass is usually on the packing list, the despatch advice, or the product master, and almost never on the invoice itself. The cleanest pattern is to hold a kg-per-unit value on the product master and multiply by the Bucket 1 quantity, with the packing list as the fallback where unit weight varies (mixed-weight food, custom-cut materials, made-to-order items). Lines where mass cannot be sourced from any of those go to Bucket 3 rather than being filled in with a guess. RPF validates net mass and supplementary unit values for plausibility, and a guessed figure that survives the check creates an inaccuracy that travels into every subsequent month.

Supplementary units. Pairs, litres, square metres, items, or kilograms net of packaging, depending on the CN code's requirement. The supplementary unit only applies where the CN code specifies one — many codes do not — and the value is in the unit the code calls for, not in whatever the invoice happens to quote. The most reliable arrangement is to extend the same SKU lookup table that holds the commodity code and the country of origin so it also holds the unit-of-measure rule and the conversion factor from the invoice quantity unit to the Intrastat unit. Populating both columns from the same lookup keeps them consistent and means a CN code change only needs to be made in one place.

Mode of transport, terms of delivery, and nature of transaction. These are shipment-level attributes. Mode of transport (road, sea, air, rail, post, fixed installation) sits with the despatch record or the carrier's paperwork. Terms of delivery — the Incoterm — sits with the purchase order on the buyer side or the sales contract on the seller side; many invoices print the Incoterm in the header as a convenience copy, but the contractual source of truth is upstream. Nature of transaction is the Eurostat code for the type of movement (outright sale or purchase, return, replacement, processing inwards, processing outwards, and so on), and the working paper should hold a default per customer or supplier where one is genuinely defaulted; anything outside the default route belongs in Bucket 3.

The pattern across this bucket is consistent: the data is structured, but it is upstream of the invoice and it is keyed on the product or the shipment rather than on the transaction. Invoice extraction tooling is not the right tool here — there is nothing on the invoice to extract — and the right tool is a maintained product-master lookup the working paper joins against. The investment is one-time per SKU with annual refreshes; the saving compounds every month.

Bucket 3: the lines that need human classification before they ship

The lines that survive Bucket 1 and Bucket 2 without auto-populating are not failures — they are the cases where neither the invoice nor the product master settles the matter and a person has to decide. The review-status flag on the working paper is the working mechanism: every line that lands here carries the flag, gets reviewed, and only clears once it has a defensible value.

Credit notes. A credit note for a prior arrival or dispatch is an adjustment to that original line, not a separate flow. Where the credit and the original sit in the same reference period, net them on the working paper before mapping into the Revenue CSV, so the period reports the actual goods position. Where the credit lands in a later month, report it in the month the credit was issued as a negative-value adjustment, keyed to the same commodity code, partner, country of origin, and country of consignment as the original line. The one move to avoid is flipping the flow: a credit on a dispatch is a negative dispatch, not an arrival, and credit notes routed into the wrong arrivals-versus-dispatches stream produce validation failures the working paper struggles to trace back.

Missing net mass or supplementary unit. Flag, do not guess. RPF rejects the upload when a commodity code requires a supplementary unit and the column is blank, and an estimated weight that survives the rejection is worse than no number at all because it travels into Revenue's statistics. The operational pattern is to surface the affected rows during working-paper review, send the SKU back to whoever owns the product master for a permanent fix (unit weight, supplementary unit rule, conversion factor), and re-run the join. A one-off manual entry on the working paper is acceptable where a single line cannot wait for the master update, but the same line failing every month is a signal the product master needs the fix, not that the working paper needs another manual override.

Dispatch customers without a partner VAT number. The headline case is cross-border B2C — a private consumer in another Member State ordering goods that physically dispatch from the trader's premises. RPF accepts the dispatch line with the placeholder value Revenue documents for the partner VAT number column on that template; check the live RPF filing guidance for the current accepted placeholder before the first such return, because the convention has changed in past template revisions and a stale placeholder fails validation. Keep this case distinct from a B2B customer who is VAT-registered but supplied the wrong number on the order — that is a Bucket 1 data-quality fix (chase the customer, update the customer master, re-extract from a corrected invoice), not a Bucket 3 placeholder.

GB and Northern Ireland movements. Since Brexit, dispatches and arrivals involving Great Britain are customs movements rather than intra-EU goods movements, and they should not be on the Intrastat return at all — they belong in the customs declaration flow. Movements involving Northern Ireland under the Windsor Framework still flow as intra-EU and stay on the Intrastat return. The practical rule for the working paper is to filter the partner country column: any line where the partner country is GB is a misclassification that needs removing before the CSV maps in, and the line should land in the trader's customs declaration workstream instead. The treatment of Ireland-UK invoicing after Brexit for GB and Northern Ireland movements sets out where the split sits at the invoice level, which is what feeds the filter.

Statistical value, for very large traders only. Statistical value is a separate column required only at the highest reporting tier; most readers are not in scope and the invoice value is the only value reported on each line. Where it is in scope, statistical value is the invoice value adjusted upward for the transport and insurance costs needed to bring the goods to the Member State border — typically an EXW base adjusted to the equivalent CIF value at the frontier. The calculation is exposure-dependent and is exactly the kind of column a finance reviewer should land on rather than an automated rule, because the adjustment varies by Incoterm, by route, and by whether transport was contracted by the buyer or the seller.

Lines that fail RPF validation at upload. RPF returns errors against the specific row and the specific column, and the working paper's reference columns — source invoice number and invoice line number — are how the team traces the error back to its origin. Fix the underlying data: in the product master where the issue is structural (a wrong CN code, a missing supplementary-unit rule), on the working paper where it is genuinely one-off (a typo in a partner VAT number, a single mis-keyed value). Do not edit the CSV template itself to make the error go away. The validation is RPF's last line of defence against Revenue receiving a bad statistic, and bypassing it pushes the problem into a query the team has to answer later.

From clean working paper to RPF upload, every month

With the three buckets reconciled, the operational tail end is short. Paste the working-paper columns into Revenue's CSV template — the arrivals template for the arrivals workbook, the dispatches template for the dispatches workbook. Because the working paper was set up in the template's column order from the start, this is a transcription rather than a reshape; nothing should need renaming, reordering, or merging at this stage.

Open the trader's RPF session, upload the CSV, and work any validation messages back to the working paper using the source-invoice and invoice-line reference columns. Once the upload validates cleanly, save the prepared return as the XML file RPF generates and submit it through the trader's ROS account. RPF is the preparation surface; ROS is where the return is actually filed against the trader's tax registration. The same upload pattern repeats each month, and once the team has run it once the sequence is short enough to be habit.

Nil returns are the case that catches teams who are above the threshold but happen to have no movements in a given month. Where the trader is registered for Intrastat on a flow but had no arrivals (or no dispatches) in the reference period, the obligation is still to file a nil return on that flow. RPF has a nil-return mechanism that submits without line data — use it. Do not skip the period in the hope no one notices, and do not submit an empty CSV in place of the nil return; both create open obligations that surface later.

It is worth being explicit that this is not a VAT3 in another costume. The VAT3 boxes for intra-community supplies and acquisitions are summary VAT figures aggregated over the period; the Intrastat return is line-level goods statistics with commodity codes, net mass, partner VAT numbers, country of origin, and Incoterms. The two returns draw from overlapping source invoices but the obligations and the field sets are different, and a team that already handles preparing the Irish VAT3 return from supplier invoices will recognise the data sources without assuming the columns carry across. They do not.

Standardise once and the recurring-month rhythm gets much shorter. Three structural pieces do most of the work: a product-master lookup keyed on SKU that holds the current 8-digit CN code, the country of origin, the supplementary-unit rule, and the unit conversion for every active product; a working-paper template that already carries the reference columns and the Revenue header order for each flow; and a documented currency-rate source the team uses every period. With those in place, the monthly cycle is the Bucket 1 refresh from the period's invoices, the Bucket 2 join against the static lookup, the Bucket 3 review of whatever residual lines need a person, and the upload. Month two is materially faster than month one; month twelve is a clerical task.

Keep the working paper, the uploaded CSV, the RPF XML, and the supplier and customer invoices that fed the return on file for the two years Revenue's guidance requires. The reference columns the working paper carried are the audit trail that makes a later query answerable in minutes rather than days.