Extract Intrastat Data From Supplier Invoices: EU Guide

An EU Intrastat arrivals declaration row is built from a fixed set of mandatory data elements, all of them extractable from the incoming supplier invoice:

The 8-digit Combined Nomenclature commodity code
The country of origin of the goods
The partner member state
The partner VAT number
The invoice value of the goods
The net mass in kilograms
The supplementary unit, where the CN code requires one
The nature-of-transaction code

Statistical value diverges from invoice value when freight and insurance have to be added under the relevant Incoterm. Where the supplier hasn't printed the 8-digit CN code, it is derived from the product description through the national tariff lookup, or carried over from the last declaration row for the same item.

This article inverts the usual treatment. The compliance-vendor pages explain the regime; the ERP documentation pages assume the structured data is already inside the ERP. Neither answers the question an AP team faces every month: how do you extract Intrastat data from supplier invoices that arrive as PDFs in the AP queue, line by line, when half of them are missing the commodity code and none of them carry the nature-of-transaction code on the page? The walk that follows takes each mandatory field and traces it from where it sits on the typical incoming supplier invoice, through the missing-data fallback, to what gets posted on the declaration row.

The focus throughout is arrivals, because arrivals are where the AP team owns the source documents. Dispatches reporting runs off shipping documents and outbound sales invoices and is owned elsewhere in the business; the field set overlaps but the workflow doesn't.

Arrivals scope and the 2026 threshold map

Each EU member state sets its own arrivals threshold under the EU framework. The 2026 picture diverges sharply across the bloc. Estonia and Finland have abandoned arrivals reporting entirely under the EU's simplification provisions, treating the buyer's recapitulative-statement obligation and the dispatch-side declarations from the supplier's member state as sufficient mirror data. At the other end, Germany sits at the top with a EUR 3 million arrivals threshold, which keeps mid-sized importers out of the obligation entirely. The dispatches side runs lower in many member states; Cyprus's dispatches threshold of EUR 75,000 is one of the lowest in the EU and illustrates how aggressively some bureaus catch outbound movements while treating arrivals more leniently. The pattern matters more than any single number: a multi-entity group with intra-community trade flows in five member states will have an arrivals obligation in some, a dispatches obligation in others, and no obligation at all in the simplification jurisdictions.

Thresholds reset annually and apply on a calendar-year basis. Once a company crosses the threshold during the year, the obligation runs for the rest of that calendar year and, under most national rules, for the following calendar year regardless of trading volume. Verify the current-year threshold for each member state where the group has a registered presence before the first declaration cycle of the year, because the figures move; several member states adjusted their thresholds upward in 2024 and 2025, and further movement in 2026 is plausible.

One housekeeping note for practitioners working on Northern Ireland Intrastat arrivals under the Windsor Framework: HMRC's Notice 60 was withdrawn, so the live HMRC Trade Tariff and the EU-side guidance are the working references rather than the legacy notice. Bookmarks and procedure documents that still link to Notice 60 should be updated.

The 8-digit Combined Nomenclature commodity code

The CN code is the defining Intrastat field. It is the EU's harmonised goods classification at the eight-digit level: the first six digits are the WCO Harmonised System code that customs authorities everywhere use, and the additional two digits are the EU-specific subdivision that pulls the classification down to the level Intrastat needs. Some national declarations require a ninth digit for a domestic statistical subdivision, but the EU-mandated reporting unit across all member states is the 8-digit code.

On a typical EU supplier invoice the code can appear in several places. Suppliers that trade across borders routinely tend to print it as a header annotation, often labelled "Tariff code", "HS code", "CN code", "Warennummer" on German invoices, or "Code TARIC" on French ones, sometimes with the eight digits broken into 4-2-2 groups for readability. Other suppliers print it as a per-line annotation in the line-items table next to each product description. Many do neither. Consolidated invoices that span multiple SKUs, invoices from suppliers who don't usually trade across borders, and invoices from small suppliers who never had to populate the field omit it entirely. This is the practitioner reality the SAP Community and AccountingWEB threads keep returning to: the supplier invoice is meant to be the authoritative source of the commodity code, and often isn't.

The missing-code workflow has a clear order of preference. The durable fix is to ask the supplier; once they have printed the code on one invoice they typically print it on every invoice that follows, and the conversation only has to happen once per supplier. Where that isn't workable for this month's run, the next step is to derive the code from the product description through the national CN lookup. The Statistisches Bundesamt's Warennummer search is the working lookup for German declarations; the HMRC Trade Tariff covers Northern Ireland under the Windsor Framework; Eurostat's RAMON reference database and the Commission's TARIC consultation tool serve the EU-wide general lookup. The third route, defaulting to the last-used code per item from prior declarations, is a maintenance-only fallback for an SKU the AP team has classified before. For a new SKU it is the wrong path; the right path is derivation from the product specification, because a wrong code propagated forward is a wrong code on every future declaration. The HS-code and commercial-invoice extraction patterns customs brokers already use translate directly to the Intrastat field set, even though the downstream filing is statistical rather than a customs entry.

The 2026 reporting year carries a Combined Nomenclature update. The eight-digit codes change for the new year, with the conversion tables published in late 2025 acting as the bridge between the 2025 codes the supplier may still be printing and the 2026 codes that need to land on the declaration. The risk is silent error: a supplier prints a 2025 code, the AP team posts it without checking the conversion table, and the declaration goes through with an obsolete code that the bureau either rejects or accepts but flags. Refresh the per-item code library against the 2025-to-2026 conversion table before the first declaration cycle of the new year, and confirm with high-volume suppliers that they have updated their own product master.

What gets posted on the declaration row is the 8-digit code, plus any national 9th digit if the reporting member state requires one. The field carries no decimal points, no spaces, no separators. A code that reads "62034210" on the invoice goes on the declaration as 62034210.

Country of origin

Country of origin is not the same as country of dispatch, and the distinction is the standing source of error in arrivals extraction. Origin is the country in which the goods were produced, manufactured, or substantially transformed under the EU's non-preferential origin rules. Dispatch is simply the member state from which the goods physically arrived. A French supplier dispatching Vietnamese-manufactured shoes from a Lyon distribution warehouse to a German buyer reports France as the partner member state and Vietnam as the country of origin. A Dutch supplier shipping German-made machinery from a Rotterdam consolidation centre to a Spanish buyer reports the Netherlands as partner member state and Germany as country of origin. Origin follows the goods; dispatch follows the shipment.

The regulatory backdrop matters because many older guides still treat country of origin as optional. According to Ireland's Central Statistics Office documentation on the 2022 Intrastat modernisation under Regulation (EU) 2019/2152, under Regulation (EU) 2019/2152 on European Business Statistics, from 1 January 2022 the partner operator's VAT identification number and the country of origin of the goods became mandatory data elements in Intrastat dispatch declarations across the EU. That EU-level mandate sits on the dispatch side. On arrivals, country of origin remains a member-state-discretion field at the EU level, but in practice every major arrivals jurisdiction the AP team will encounter, including Germany, France, Italy, Belgium, the Netherlands, Spain, Poland, and Ireland, requires it on arrivals declarations through national implementation. Treat country of origin as effectively mandatory for arrivals practice; the legacy "optional on arrivals" guidance is wrong for any volume of trade with the major EU economies.

Where origin appears on a typical supplier invoice depends on the supplier. The cleanest case is a per-line annotation in the line-items table, often labelled "Country of origin", "Origin", "Made in", "Herkunftsland" on German invoices, or "Pays d'origine" on French ones. Where every line on the invoice shares an origin (a single-origin shipment), some suppliers print it once as a header field. The harder cases are consolidated invoices that span multiple SKUs from multiple origins, where origin is often not on the invoice itself but on the packing list or on a certificate of origin attached as a separate page. Some suppliers omit it entirely.

The missing-data workflow uses the goods themselves as the strongest fallback. The country-of-manufacture marking on the product, the "Made in X" label that consumer-protection rules require for many product categories, is the most common practical source. The supplier's packing list and any attached certificate of origin are the next layer. Where the AP system holds a product master with origin per SKU from prior trade, the master record is a reliable reference for repeat items. Only for processed goods that crossed several jurisdictions during manufacture does the AP team need to fall back on the EU non-preferential origin rules, applying the substantial-transformation test to determine which jurisdiction qualifies as origin. That last route is rare in routine AP and worth flagging for indirect-tax review when it comes up.

What gets posted on the declaration row is the ISO 3166-1 alpha-2 country code: DE for Germany, VN for Vietnam, US for the United States, GB for Great Britain, CN for China. One code per declaration row; mixed-origin lines need to be split into separate rows by origin code before the declaration is built.

Partner member state and partner VAT number

These two fields come from the same address block at the top of the supplier invoice and are best handled together, because the validation step on the partner VAT number also acts as the filter that keeps non-EU supplier invoices off the Intrastat run.

Partner member state is the supplier's country, posted on the declaration as the ISO 3166-1 alpha-2 code (DE, FR, NL, IT, ES, BE, IE, PL, SE, AT, CZ, and so on). It is derived directly from the supplier address block on the invoice header and is distinct from country of origin: a Dutch supplier shipping German-manufactured goods reports NL as partner member state and DE as country of origin, and the two fields are independent on the declaration row.

Partner VAT number is the supplier's intra-community VAT identification number, prefixed with the country code: DE123456789 for a German supplier, FR12345678901 for a French supplier, NL123456789B01 for a Dutch supplier, IT12345678901 for an Italian supplier. It sits in the supplier's VAT registration block, usually printed under or beside the supplier address, sometimes in the invoice footer. This is the same number that the buyer reports on its recapitulative statement (the EC Sales List equivalent in each member state), the VAT-side counterpart to Intrastat. One number, two outputs: the recapitulative statement records the buyer's intra-community acquisition for VAT purposes, and the Intrastat row records the goods movement for statistical purposes.

The partner VAT number must be validated against VIES before it goes on the declaration. A failed VIES check is a hard signal that something is wrong: the supplier may have deregistered, the number may have been mistyped on the invoice, or the supplier may not in fact be established in the EU and the goods may have arrived through some other movement that doesn't qualify as an intra-community acquisition. Posting an Intrastat row against an invalid partner VAT number is not a soft error; the national bureau's mirror-trade reconciliation will fail to pair the buyer's arrival declaration with the supplier's dispatch declaration, and the row will be flagged for query. The Cyprus VIES guide on validating an EU partner VAT number before it goes on a recapitulative statement is a worked example of the validation discipline; the same VIES check serves the Intrastat run.

The disqualifier point is the practical filter rule. If the supplier is non-EU, a UK supplier post-Brexit other than under the Northern Ireland arrangements of the Windsor Framework, a Swiss supplier, a Norwegian supplier, the invoice is not an intra-community arrival and does not belong on the Intrastat declaration at all. Those goods enter the reporting member state through a customs declaration (a single administrative document or its electronic equivalent), and the customs data feeds Extrastat statistics on the EU side rather than Intrastat. The simplest filter at the front of the AP queue: partner VAT number begins with an EU member-state country code, or the invoice doesn't run on the Intrastat job. Apply the filter before any other field extraction, because non-EU invoices have no Intrastat row no matter how complete the other fields are.

What gets posted on the declaration row is the partner VAT number as a single string (country code plus the national number, no spaces, no dashes, no formatting), and the partner member state code separately as the alpha-2 ISO code.

Invoice value, statistical value, and where they diverge

The value field is where the cleanest practitioner trap sits, because the figure that drives the reverse-charge VAT entry is not always the figure that goes on the Intrastat row.

Invoice value of goods is the taxable amount on the supplier invoice net of VAT. Intra-community supplies are zero-rated in the supplier's hand under the EU VAT directive, so the supplier invoice carries the goods value before any VAT calculation; on most supplier invoices the net and the gross are the same number. That goods value is the figure that goes in the value column of the declaration where the reporting member state asks only for invoice value, which is the simpler of the two cases.

Currency conversion sits on top of that. Most reporting member states require the value in the national reporting currency: euro for the eurozone, the national currency for Sweden (SEK), Czechia (CZK), Denmark (DKK), Hungary (HUF), Poland (PLN), and Romania (RON). Each member state prescribes the conversion rate, typically the customs rate of exchange the national customs authority publishes monthly, or the European Central Bank's reference rate for the relevant period. Set the conversion rate per declaration period at the start of the period and apply it consistently across every invoice in that period; converting per invoice at the day's spot rate produces drift between the Intrastat figures and the reverse-charge VAT figures that have to reconcile to them.

Statistical value is a separate field that some member states still require alongside invoice value, particularly for higher-value declarations or specific commodity groups. The definitional point is that statistical value is the value of the goods at the point they cross the reporting member state's border, not at the supplier's premises. Under CIF or CIP-equivalent Incoterms, where the supplier's price already includes carriage and insurance to the buyer's country, statistical value equals invoice value because the freight and insurance up to the border are already inside the figure on the invoice. Under EXW or FCA-equivalent Incoterms, where the buyer arranges and pays for transport from the supplier's premises onward, the adjustment runs the other way: the freight from the supplier to the border has to be added to the invoice value to produce statistical value, even though that freight cost arrives on a separate invoice from the carrier.

Incoterms drive the adjustment, and Incoterms typically appear in the invoice header as a delivery term ("DAP Frankfurt", "EXW Lyon", "FCA Hamburg"), sometimes in the supplier's terms-of-sale block, occasionally only in the contract that the invoice references. Read the Incoterm first: it tells the AP team whether freight and insurance are already in the invoice value, in which case statistical value equals invoice value, or whether they need to be added, in which case statistical value is the invoice value plus the freight and insurance costs to the reporting member state's border. Practitioners new to the field underestimate how much of the work is upstream of the value calculation: pulling the Incoterm correctly off the invoice is what determines whether the statistical-value figure is correct. The mechanics of how Incoterms on the commercial invoice drive what gets added to statistical value deserve a separate read for any AP team standing up an Intrastat workflow for the first time.

The recurring trap is a supplier invoice under EXW with a separate freight invoice from a third-party carrier. The clerk who copies the supplier invoice net into both the invoice-value field and the statistical-value field underreports statistical value, because the freight to the border is missing. The clerk who copies the supplier invoice net into invoice value and posts zero into statistical value also underreports, on the same logic. The correct posting requires the freight cost to the border, taken from the carrier's invoice, to be matched to the supplier invoice and added to the statistical-value figure for the row. This match is the single most common reason monthly Intrastat numbers fail to reconcile to expected goods values, and it tends to compound across an arrivals run unless the AP team has a defined procedure for pairing carrier invoices to supplier invoices before the Intrastat extraction.

One simplification is worth knowing about. Most member states have abandoned the statistical-value field on arrivals declarations after the 2022 EU simplification, keeping only invoice value to reduce the burden on declarants; the field still exists on dispatch declarations and on arrivals in a small number of member states for specific commodity groups or above-threshold value lines. Verify before the first declaration cycle whether the reporting member state asks for statistical value at all on arrivals; where it doesn't, the entire freight-and-insurance adjustment is irrelevant for the Intrastat row, though it remains relevant for landed-cost calculations.

Net mass and supplementary unit

Net mass and supplementary unit are the two quantitative fields on the declaration row, and they sit awkwardly on the supplier invoice for different reasons. Net mass is mandatory on every row but rarely on the invoice header; supplementary unit is mandatory only when the CN code requires one, but where it is required, it usually doesn't match the unit the supplier sells in.

Net mass is the weight of the goods themselves in kilograms, excluding all packaging: cartons, pallets, dunnage, plastic wrap, internal padding. The distinction from gross mass matters, because gross mass appears far more often on supplier paperwork than net does, and copying a gross figure into the Intrastat field overstates the reported net mass. Some member states accept decimal kilograms for low-mass items (jewellery, electronic components); others round to whole kilograms. Verify the rounding rule for the reporting member state before the first declaration cycle.

Net mass rarely appears on the invoice header. The reliable source is the packing list that travels with the shipment, where the supplier states a per-line net weight as part of the consignment documentation. Where the AP system holds a product master with unit weight per SKU from prior trade, multiplying unit weight by line quantity is a sound derivation. Net mass cannot be reliably derived from the invoice alone, which is why an AP team running Intrastat needs the packing list integrated into the supplier-invoice processing flow as a matter of course, not as an exception. The teams that struggle with net mass at month-end are usually the teams that don't capture the packing list at the point the invoice arrives.

The missing-net-mass workflow is straightforward in order: pull from the packing list first, because it is the supplier's own statement of net weight; derive from the product master per SKU where the packing list is missing; ask the supplier and request that future packing lists carry per-line net mass, which is the durable fix; estimate from gross mass minus a standard packaging-weight allowance only as a last resort, and only where the supplier publishes packaging specs that make the estimate reproducible.

Supplementary unit is the second quantitative field and the more conditional one. It is required only for CN codes that mandate one. The CN tariff line itself carries the flag: each eight-digit code either has a supplementary unit specification or does not. Common supplementary units include litres for beverages and certain liquid chemicals, square metres for textile rolls and panel products, pieces for assembled units like furniture and machinery, pairs for footwear and gloves, and number of articles for various manufactured goods. For codes that do not require a supplementary unit, the field is left blank on the declaration; for codes that do, it is mandatory, and a missing supplementary unit triggers a query.

Where the supplementary unit appears on the supplier invoice is typically as the line-item quantity, in the unit the supplier prices in. The recurring complication is that the supplier's commercial unit doesn't always match the CN supplementary unit. A supplier prices a wine consignment per case of twelve bottles; the CN code for that wine requires litres. A supplier prices a textile consignment per metre; the CN code requires square metres. The conversion is part of the AP-side preparation, and the product master is the natural place to hold the conversion factor per SKU so the conversion is consistent month to month. Holding the factor at the SKU level also means a price change at the supplier doesn't break the Intrastat figure.

What gets posted on the declaration row is net mass as a whole-kilogram value (or decimal where the member state allows it), and supplementary unit as a quantity in the CN-prescribed unit, blank where the CN code does not require one.

Nature-of-transaction code

The nature-of-transaction code is the field that catches AP teams new to manual Intrastat preparation, because it isn't printed on the invoice and most ERPs handle it silently in the background when an integrated module is doing the declaration. Pulled out of the ERP context, it requires the AP team to read the invoice and post the right code from the EU statistical taxonomy.

The code is two digits describing the commercial purpose of the goods movement under the EU's Nature of Transaction taxonomy, harmonised across member states under Commission Regulation (EU) 2020/1197 and its successor acts. The first digit is the broad category, the second digit is the subdivision within that category. The codes that cover the bulk of arrivals traffic are 11 for outright purchase or sale of goods, 12 for goods sent on approval or for trial before final sale, 21 for return of goods previously dispatched, 31 for goods sent for processing under contract where the goods will return to the dispatching country once the work is done, 41 for goods following processing under contract (the inbound side of the same arrangement), and 91 for hire or operational leasing of twelve months or more. Other codes exist for specific cases such as financial leases, sales of assets between related entities, and goods sent for repair, but the codes above cover the routine AP queue.

The code is not printed on the invoice. The AP team derives it from the invoice's commercial context. A routine purchase order delivery against an open buying contract is code 11. A credit note for a return is code 21. A delivery from a contract processor returning goods after subcontract work is code 41. The judgment is on the commercial pattern, not on any field on the page. For most AP queues, the overwhelming majority of arrivals are code 11; the override cases appear when the goods movement isn't a simple buy.

The practical rule is to default code 11 for standard purchase invoices and override only where the invoice context signals something else. Returns, replacements, samples, processing flows, and operational leases are the override cases, and they are recognisable from the invoice (a credit note posted as an invoice, a "no-charge sample" annotation, a processing fee on the line item with no goods cost, a leasing reference). Document the mapping in a per-supplier or per-document-type rule so that the same commercial pattern always produces the same code; the bureaus look for stability of nature-of-transaction coding across periods and a sudden shift triggers a query even when each individual posting was correct.

The EU code list is harmonised, but national declarations can vary in two ways. Some member states accept a one-digit summary version (just the first digit of the EU code), and some have national subdivisions sitting underneath the EU two-digit structure for specific use cases. Verify the code list in use for the specific reporting member state's declaration template before the first run; thereafter the codes are stable across reporting periods unless the member state issues a new declaration template.

What gets posted on the declaration row is the two-digit code (or one-digit, where the member state simplifies). No commentary, no transaction description, no narrative.

One supplier invoice, two different statutory outputs

The same intra-community supplier invoice that produces the Intrastat row also produces the reverse-charge VAT entry, and the two outputs do not share data shape. Practitioners who treat them as one workflow with two filing destinations end up with reconciling errors at month-end; treating them as two distinct posting workflows from the same source document is what keeps the numbers tidy.

The intra-community-acquisition VAT entry sits on the buyer's national VAT return. The buyer charges output VAT to itself at the reporting member state's rate on the goods value, recovers input VAT in the same period (subject to the buyer's general right of deduction), and the net VAT effect is zero in most cases. The fields that drive that entry are the supplier's VAT identification number, the partner member state, the goods value, the VAT rate applicable in the buyer's member state for those goods, and the box-by-box mapping the national VAT return imposes. The Intrastat arrivals row is a separate filing into the national statistical bureau, and its fields are the eight described in this article: CN code, country of origin, partner member state, partner VAT number, invoice value of goods, net mass, supplementary unit, nature of transaction.

The shared fields are partner VAT number, partner member state, and invoice value of goods. The diverging fields are the rest: the VAT entry needs the VAT rate and box mapping; the Intrastat row needs the CN code, country of origin, net mass, supplementary unit, and nature of transaction. The shared fields are also where reconciliation pressure lands. The partner VAT number on the Intrastat row must match the partner VAT number on the recapitulative statement (the EC Sales List equivalent) for the same period; mirror-trade reconciliation across member states pairs the supplier's dispatch declaration to the buyer's arrival declaration through the partner VAT numbers, and a mismatch is a guaranteed query. Reconcile pre-submission, not post.

The common error is value bleed between the two outputs. A supplier invoice that combines goods value and freight on the same line, without separating them, produces a VAT-return figure (the full invoiced amount, on which the buyer charges and recovers VAT) that doesn't match the Intrastat invoice-value figure (the goods value alone, with freight either excluded entirely or moved into statistical value depending on the Incoterm). The clerk who copies the VAT figure into Intrastat overstates the goods value; the clerk who copies the Intrastat goods value into the VAT return understates the taxable amount. Treat the two outputs as separate posting workflows with the supplier invoice as a shared source: the goods value, freight component, and any other invoice items get separated once at extraction, then routed to the correct destination in the correct shape.

A useful reference point for AP teams running both EU and UK processes is the post-Brexit UK case. The intra-community VAT mechanic doesn't apply on UK arrivals; instead, the supplier invoice and the postponed VAT accounting statement on the HMRC side reconcile to one another, with the postponed VAT statement standing in for the import-VAT entry that would otherwise have been paid at the border. The same one-document-two-outputs framing applies, with different VAT mechanics: the goods data on the supplier invoice has to reconcile to the postponed VAT figure on the HMRC statement for the same shipment. The UK Postponed VAT Accounting guide for the parallel HMRC-side reconciliation on the same imports walks through that mechanic in detail for any AP team handling both EU intra-community arrivals and UK post-Brexit imports.

From manual rekeying to a structured rowset

The walk through eight fields makes one thing concrete: the difficulty isn't any single field. It's the multiplication. Eight fields per declaration row, one row per line item, dozens or hundreds of supplier invoices per arrivals run, every month. Manual rekeying scales linearly with the queue, and the queue grows. The packing-list lookup for net mass, the VIES check for partner VAT, the national tariff lookup for missing CN codes, and the per-SKU history check for last-used codes each take a few minutes; aggregated across an arrivals run they take a working week.

A prompt-based extraction inverts that arithmetic. The AP analyst names the eight Intrastat fields once in a prompt, applies the prompt to a batch of intra-community supplier-invoice PDFs, and gets back a structured rowset (one row per line item) ready to populate the national declaration template. The same prompt runs against next month's batch and the month after with no reconfiguration; the configuration is the prompt itself, not a templating exercise that has to be redone per supplier or per layout. Our AI-powered extraction platform that pulls Intrastat fields straight from supplier-invoice PDFs is built on exactly that interaction: a single prompt field, a batch upload area, an Excel or CSV file out at the end.

A working prompt for the Intrastat run is short. An analyst might write something like: extract invoice number, supplier VAT number, partner member state, country of origin, 8-digit CN code, net mass in kilograms, supplementary unit where applicable, invoice value of goods, and nature-of-transaction code (default to 11; flag any invoice whose context suggests an override); produce one row per line item, repeating header fields on each row; format dates as YYYY-MM-DD; include the source file name and page number on each row for cross-reference. That prompt covers the field set, the row structure, the formatting discipline, and the audit trail in five lines. Saved to a prompt library, it runs every month against the new batch with no analyst time on configuration.

The capability that matters specifically for Intrastat is the source-file and page reference per row. Mirror-trade reconciliation queries from the national bureau land on individual rows, and the practical question is always: which supplier invoice did this row come from, and which page of that invoice carries the field the bureau is querying? A rowset that carries the source file and page reference per row answers that question in seconds; a rowset that doesn't answer it forces the AP team back into the original PDF stack to find the line. The cross-reference attribute is the one that turns a structured-extraction run into something audit-defensible.

The same extraction discipline feeds adjacent finance workflows on the same supplier invoices. A landed-cost workflow that consumes the same supplier-invoice + freight + duty document set uses the goods value, freight, duty, and CN code that the Intrastat run already extracted, with different downstream arithmetic but the same source records. Once the supplier-invoice PDFs flow through a structured-extraction step, the rowsets are reusable across Intrastat, reverse-charge VAT reconciliation, landed-cost calculation, and the country-of-origin reporting that compliance functions increasingly need on top.