How to make Swell EU compliant

[maartenb17]

Maybe I have overlooked something but Swell doesn't seem to be fully compliant with EU-invoicing-rules.
First Swell makes a distinction between orders and invoices with different numbering. In EU one time purchases or recurring payments are considered the same fiscally and therefor requiring a unified numbering logic.
Although official sales documents (invoices in EU terms) can be in any format (like the current email notifications), downloadable invoices in pdf format are expected. xml for automatic processing in accounting software is also common. Indeed these are two standard formats customers expect to receive by email and optionally to download from a portal.
I am about to develop a solution for myself bypassing Swell's notifications using my accounting platform instead, but I reckon that this should be standard Swell functionality if you guys are serious about the EU market. It could co-exists with the current notification system.
In the EU Invoices (both orders and invoices in Swell are considered as one and the same) must contain the following information:

•	Unique sequential invoice number
•	Invoice date
•	Supplier name, address, VAT number
•	Customer details (VAT number for B2B intra-EU)
•	Description of goods/services
•	VAT rate and VAT amount
•	Total amount
•	Date of supply (if different from invoice date)

And it must ensure:
• Authenticity of origin
• Integrity of content
• Legibility

So in short:

• Homogenise invoice and order numbering (this could be a system setting)
• Store invoices and orders as pdf's or generate them when requested (system setting)
• Add UX and corresponding data fields.

BTW there are some other settings in Swell that now needs to be configured manually to comply with EU-laws. This is quite labor intensive. I imagine a system setting to set Swell to standard EU-norms like VAT, notifications etc. (which can be overridden manually if needed). Maybe even when onboarding asking new customers to choose where they are from which determines what they see. Under the hood it still remains the highly customisable headless e-commerce platform as it is today.

Anyway thanks for considering!

[ericingram]

Thanks for the detailed feedback

We keep separate order and invoice numbers to support flexible recurring + fulfillment workflows (i.e., standalone recurring invoices). For EU compliance, treat invoice.number as the primary fiscal reference for subscriptions, or order.number as the primary reference otherwise.

We're looking into:

• Settings to prioritize invoice numbering on PDFs/emails
• Native invoice PDF generation + portal downloads
• Better EU field/onboarding support

This is on our radar

[maartenb17]

You are actually correct! As long as each numbering sequence is distinguishable by using a different prefix. For orders I can do that in settings but for invoices I can’t. Met vriendelijke groet,MaartenVerstuurd vanaf mijn iPhoneOp 26 feb 2026 om 16:18 heeft Eric ***@***.***> het volgende geschreven: Thanks for the detailed feedback We keep separate order and invoice numbers to support flexible recurring + fulfillment workflows (i.e., standalone recurring invoices). For EU compliance, treat invoice.number as the primary fiscal reference for subscriptions, or order.number as the primary reference otherwise. We're looking into: Settings to prioritize invoice numbering on PDFs/emails Native invoice PDF generation + portal downloads Better EU field/onboarding support This is on our radar —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>