Part III - Feedback & Enhancements – TAX ID field logic & VIES verification. V.1.1.1.

Tindaro Battaglia not yet, to my knowledge.

Right now you can only toggle some custom fields for the checkout and make some customizations at a page level.

Tindaro Battaglia the checkout is one single block as of now which is not changeable. You can out elements around it, but not into it.

Andre Daus Appreciate your insights Andre!! - and fully agreed on several of your points.

Let me add a few legal nuances for clarity and future-proofing.

1️⃣ On VIES - absolutely. It’s unreliable by nature - even the European Commission admits that 😂- so any implementation should be resilient, not dependent.

The key isn’t to trust VIES, but to gracefully handle its absence while still staying compliant.

2️⃣ Fiscal ID ≠ EU VAT ID: when I mentioned it’s mandatory in B2B, I wasn’t referring to the EU VAT number specifically, but to the fiscal identifier in general (NIF, VAT ID, USt-IdNr, etc.).

Across Europe, every business has one.

Eg.: In Spain, for instance, the buyer’s tax ID is compulsory on all B2B invoices, domestic or otherwise - under both national invoicing rules and Article 226 of the EU VAT Directive. In Germany, the VAT ID only becomes essential for intra-EU reverse charge (same for other EU member states), but a fiscal identifier still exists and must appear on formal invoices.

And that requirement is only tightening. With the upcoming wave of electronic invoicing mandates (Spain’s Ley Crea y Crece and VeriFactu, the EU’s EN 16931 / PEPPOL standard, and the VAT in the Digital Age (ViDA) package / the buyer’s tax ID will be a technically required field).

If it’s missing, e-invoicing systems will simply reject the file. In other words: issuing B2B invoices without a fiscal ID is not just risky - it’s an audit magnet…

So yes: the field should remain optional for B2C (and this, of course, taking into account the amount, because it could also be mandatory for B2C), but always available for B2B. Because what’s “optional” in design quickly becomes obligatory in compliance.

3️⃣ On T&C checkboxes. The checkbox itself isn’t what the “law requires”; what matters is the evidence of informed consent.

Courts across the EU (particularly in Spain and Germany, among other EU member states) consistently accept a timestamped checkbox as powerful proof (only if you can prove content). It’s not the law itself, it’s the forensic trace that satisfies it.

4️⃣ VAT labeling - fully aligned. As mentioned before, naming the tax, showing the rate and amount isn’t cosmetic; it’s required under many EU member shops regarding the EU Directive. Transparency here is legal compliance in disguise.

In short - we’re aligned on principle: flexibility, compliance, and traceability.

Nuances are key, though :)

That’s the beauty of FluentCart: it gives merchants the ability to respect national nuance without ever stepping outside EU law. But it definitely need important engagements so as to allow the merchants to be fully compliant in their respective markets.

Jorge de los Reyes Regarding #2, are you referring to the ID of the merchant or of the buyer? Because having a VAT ID (USt-ID in Germany) is optional. No business is obliged to get one in general. If I set up a shop and want to sell to the German market only, I can do so without a VAT ID. In that case, I'd put my fiscal ID (Steuernummer in Germany) onto the invoice.

I was referring to the VAT ID field on the checkout (the one the clients fills usually to issue a reverse charge calculation). The field must be optional there.

I am more concerned about the German PAngVO, where are are obliged to show the gross amount of products. It is not sufficient to show the net amount and tax separately (the legislation seems to think that not everyone can sum up these two numbers, hence, the merchants need to do this for them). So, on the overview there must be a gross amount and on the details page there needs to be a breakdown with value and percentage. If the user enters their VAT ID, we must show the net amount (given we're registered for reverse charge and have a VAT ID). I wanted to test this, but taxes do not work anymore in the latest version. I am waiting for the fix.

Andre Daus hello Andre!

To be precise, I was referring to the buyer’s fiscal identifier, not strictly the VAT ID (USt-IdNr).

You are absolutely correct that, in Germany (like in any EU member state), a domestic merchant may operate using only a Steuernummer (TAX ID), and that obtaining a VAT ID is optional unless trading cross-border.

It’s the same in every EU Member state.

However, the legal nuance here comes directly from Article 226 of the EU VAT Directive 2006/112/EC (which will be very famous again pretty soon with all the new ViDA enhancements).

This article explicitly requires that:

“the customer’s VAT identification number, as referred to in Article 214, [must appear] under which the customer received a supply of goods or services in respect of which he is liable for payment of VAT.”

In other words, whenever the customer is a taxable person and liable for VAT, the invoice must include their fiscal identifier -whether that’s a VAT ID or a domestic equivalent (NIF, Steuernummer, etc.).

And under Article 227, Member States may even extend that obligation to other cases.

That’s why I mentioned that there are nuances 😄

Spain, for instance, transposed this by requiring the NIF on all B2B invoices, even domestic ones. Germany limits it mainly to intra-EU supplies, but the EU legal base is almost thr same in all EU.

What’s more, the forthcoming digital-reporting and e-invoicing frameworks make this requirement de facto technical:

• 🇪🇸 Spain mandate structured e-invoices including both parties’ tax IDs.
• 🇪🇺 The EU’s “VAT in the Digital Age (ViDA)” package and EN 16931 / PEPPOL standards already treat the buyer’s fiscal ID as a mandatory data field.
  If that field is missing, e-invoicing systems will reject the file - and during audits, that omission is nearly always treated as a compliance fault. That’s why many European are a bit “nervous” regarding their softwares integration capabilities. Because we need to be able to check this VAT rulings.

So yes, you’re right that the checkout VAT ID field must remain optional (since not every buyer has a VAT ID), but merchants must still be able to capture a Tax ID / Fiscal ID when needed.

Otherwise, they risk issuing invoices that fail to meet legal or technical standards (not just local, but the EU compulsory ones) especially in B2B contexts subject to digital reporting.

Regarding your PAngV point, completely agreed!

Again, it’s the same for any EU Member state.

Eg.: German law requires displaying the gross price (tax included) in all consumer offers, and showing both rate + amount in the breakdown.

Only once a valid VAT ID triggers reverse-charge does the net display apply.

That’s a general ruling in EU.

And also aligns perfectly with the structure FluentCart should support:

• B2C: Gross prices with VAT visibles

• B2B Domestic: fiscal ID; VAT charged as usual.

• B2B Intra-EU: VAT ID required; reverse charge applies; net prices shown.

  in the end, flexibility to make it optional when applicable.

In short: the optional VAT ID field is correct from a UX point of view, but legally, the presence of a fiscal identifier remains indispensable for compliant invoicing under both Directive 2006/112/EC and the new digital-reporting standards soon to be enforced across the EU.

Most e-commerce softwares, simply, use the same EU VAT field for complying with this must-have tax ID identification.

And that’s why I was referring the needed enhancement 😄

I am not using the build-in invoicing. That's mainly why I just focused on the checkout, client-facing fields.

Andre Daus Makes sense, Andre 😄

However, even without built-in invoicing, checkout is still the compliance entry point.

That’s why the field should accept any fiscal ID, not just EU VAT.

it’s the data every e-invoicing or audit system (VeriFactu, PEPPOL, ViDA) relies on, and what will ultimately allow businesses across Member States to interconnect their invoicing solution.

So…yep! We should be keeping an eye on this for future updates 😄

Andre Daus schreibst du mit FCart Rechnungen dann manuell oder wie automatisierst du das?

Manuel Müller I send them to my accounting which handles all the rest via webhooks.