Collecting a tax ID at checkout, for the countries that actually need one

Selling into more than one country eventually produces the same request from finance: the order needs a tax identification number on it. Which number depends entirely on where the buyer is. A VAT or EORI number in Europe, PAN in India, CPF in Brazil, RFC in Mexico. Each has its own name, its own length, its own idea of what a valid value looks like, and its own answer to whether a private customer needs one at all.

Adobe Commerce and Magento Open Source have no place to express that. The checkout knows the shipping country, and it knows how to render a field, but nothing connects the two. So the field gets added in code – a plugin, a layout processor, a validator, a save handler – and then again for the next country, and again when a rule changes.

What it is for

Checkout Tax ID Fields turns that into configuration. A rule names one or more countries, the label the customer sees, the tooltip beside it, how the value is validated, and whether it is required. When a customer picks a shipping country that a rule covers, the field appears in the shipping step. When they submit, the value is saved to the order together with a snapshot of the label it was collected under.

That last detail matters more than it sounds. Labels change – a country renames its identifier, a legal team rewrites the wording, a rule is edited two years later. An invoice raised against an old order still has to show what the customer was actually asked at the time, not what the current rule happens to say. The snapshot is what makes that true.

How it can be used

One country, one number. The simplest shape: India needs a PAN, so a rule covers India, labels the field, requires it, and validates it as ten characters. Ten such rules ship with the extension – India, Brazil, Indonesia, Mexico, Saudi Arabia, South Korea, Turkey, Vietnam and Bangladesh, plus a combined EU and Great Britain EORI rule – so the common cases work before you configure anything.

Many countries, one rule. The EORI rule covers twenty-eight EU countries and Great Britain in a single entry, because the format is the same across all of them. Adding a country to an existing rule is one field, not a deployment.

Two numbers for one country. Separate Residential / Commercial mode gives a country two independent fields with their own labels, validation and required flags. A private buyer sees a personal identifier; a company sees the EORI box. The customer chooses with a switch above the field, and the field reconfigures itself. This is the case that usually forces custom code, because it is not one field with a condition – it is two fields that never appear together.

Optional where it should be optional. Required is per rule. A country where the number helps but is not mandatory gets a field the customer can skip, and the order records whichever answer they gave.

Once the value is on the order it is visible where order data is normally read: on the order detail page in the admin panel, and as an opt-in Tax ID column in Sales → Orders that filters and sorts server-side. Nothing has to be exported to be looked at.

How it compares

Extensions that touch a tax identification number tend to do one of two other jobs. Some verify an EU VAT number against the European registry, which answers a different question – is this number real – and only has meaning inside the European Union. Others collect extra fields somewhere else in the journey, at registration or on an invoice, or hand you a generic custom-attribute box and leave the country logic to you.

This one is neither a validator nor a registration form. It is a rule engine for a question the checkout already has the answer to: given this shipping country, which identifier should this customer be asked for, and what does a plausible one look like. That is why it covers PAN, CPF, RFC and EORI as readily as VAT, why one rule can serve twenty-nine countries at once, and why a private buyer and a company can be asked for different numbers in the same country without a line of code.

What it does not try to be

It is not a tax engine. The value is collected and stored; totals, tax rules and invoices are untouched by it. It is not a compliance service – validation is by length or pattern, the extension makes no external calls of any kind, and a well-formed but fictitious number will pass. It is not a customer-profile feature: the number belongs to the order, not to the account.

It is rule-based and deterministic, it runs entirely on your own infrastructure, and it adds one database table without altering a native Magento sales table. Everything it does can be read out of the admin panel and verified in the order it wrote.