E-Invoicing (EU)

Overview

Generates EU-compliant electronic invoices that align with regional regulations for automated tax-ready billing.

Key concepts

Key terms, statuses, and records that appear in E-Invoicing (EU) in XFatora.

Setup & prerequisites

Connect required settings, templates, and defaults for E-Invoicing (EU) in XFatora.

Roles & permissions

Assign role-based access, approvals, and visibility for E-Invoicing (EU) in XFatora.

Main workflows

E-Invoicing (EU) module

helps your business comply with European electronic invoicing standards, particularly when dealing with government entities or cross-border EU trade that requires standardized e-invoices. It automates the creation of invoice files in approved formats (like

UBL XML for PEPPOL

), ensuring your invoices contain the required information and format for electronic transmission. In short, this module saves you from manually preparing XML invoices and helps you

stay compliant with EU e-invoicing directives

.

What is E-Invoicing and Who Needs It?

Understanding E-Invoicing:

Electronic invoicing in the EU often refers to sending invoices in a structured data format (not just PDF) that can be automatically processed by the recipients software. Many public administrations in the EU require suppliers to send invoices via networks like

PEPPOL

in UBL format. The E-Invoicing module generates these structured files (XML) for you, so you can send them via such networks or upload to government portals as needed.

When to Use:

If you have to invoice a government department in an EU country, they likely mandate e-invoicing. Also, some large companies and B2B contexts prefer or require it. Even if not forced, using e-invoices can reduce errors and processing time. You will continue to use the standard invoicing in the system for the business logic (creating invoices, etc.), then use the E-Invoice module to

export an invoice in the EU-compliant format

that corresponds exactly to the original.

Compliance:

The module is configured to comply with EU standards such as

EN 16931

(the European norm for e-invoices). It knows what data fields are required (e.g. seller and buyer VAT numbers, IBANs, line item VAT breakdowns, etc.). It will alert you if required info is missing from an invoice before generation (for example, if your companys VAT or the clients electronic address ID isnt set, itll require those).

Setup Requirements

Company Details:

In

Settings > Company Information

, ensure all your company details are filled: legal name, address, VAT number, registration number, etc. Specifically for e-invoicing, fill any fields like

Company Electronic Address

and

Electronic Address Scheme

if provided. Some countries use specific identifiers (like a government-assigned code or a GLN). The module might store these as options (the scheme might be something like

GLN

,

VAT

,

SMN

depending on what ID the recipient expects). For your own company, the Seller Electronic Address and scheme are needed for the XML to identify you properly.

Customer Data:

For each customer that will receive an e-invoice, you need to have their

Electronic Address and Scheme

recorded. This could be, for instance, a PEPPOL ID. In practice, a customers electronic address might be their VAT number or a specific code given to them in the e-invoicing network. The module likely adds custom fields to the Customer profile for Electronic Invoicing Address and a dropdown for scheme (like

0007

for a Swedish Org. number,

9906

for a Danish VAT,

9930

for a GLN, etc.). Obtain these from your client or from the PEPPOL directory if available. Without these, the system wont generate the invoice.

Invoice Fields:

Ensure that your invoices have all the necessary data filled in: invoice date, due date, payment terms, at least one line item with clear description, quantity, unit price, and tax applied. E-invoicing mandates explicit breakdown of VAT (tax rate and amount for each rate used). So always apply the correct tax rates to each line item (the module will include those in the XML). If an invoice is tax-exempt or reverse-charged, you might need to include specific reference in the invoice (like a reason code or text in a notes field); the module likely handles standard tax codes but check if any manual step is needed for special cases.

Custom Fields:

Some e-invoice recipients require extra references (like a purchase order number, contract number, or department code) to be present in the e-invoice. Often these can be filled in the invoices reference field or a custom field. The module might map certain fields (e.g. the Reference # field on an invoice or a custom field like Order Number) into the XML. Before generating, fill those in if needed. For example, a government might say include PO number in the invoice put that in invoice reference so it goes to the e-invoice file in the appropriate tag.

Generating an E-Invoice File

Invoice Creation:

First, create the invoice in the system as usual (via Sales/Invoices). Confirm all details as mentioned. Mark it as sent/approved as per your normal workflow. Its advisable to generate the e-invoice once the invoice is finalized (you likely shouldnt edit the invoice after sending out the e-invoice XML, to avoid mismatches).

Generate E-Invoice Action:

Navigate to

E-Invoicing

in the menu. You might see a list of invoices eligible or a form to input an invoice ID. The module provides an action like Generate E-Invoice or Create UBL for a chosen invoice. Select the invoice you want to generate (if you came via the invoices page, perhaps theres a direct button Generate E-Invoice). The system will then validate required fields: it will check for your company info, the customer e-invoice address, and any mandatory invoice fields. If something is missing, it will stop and give an error like

Electronic address for client is required

. Fix any issues then retry.

PEPPOL/Country Preset:

The module might ask to choose a

format or country

preset (some invoices need country-specific flavor like CIUS for Italy or Spain). Often it can auto-select based on customer country, but confirm. For example, it might automatically use the Italian CIUS (FatturaPA) if client country is IT, or Spanish (Facturae) for ES, etc., because certain fields differ. If it doesnt prompt, assume it chooses correctly by country as seen in code snippet where it picks preset based on ISO country code.

XML Creation:

Once initiated, the module will compile the invoice data into the structured format. This includes: seller info (your company with VAT, addresses), buyer info (customers official name, VAT/Org number, e-address), invoice details (number, date, due date, currency), line items with quantity, unit price, line amount, description, tax category (each line likely gets a tax category node in XML with tax rate and tax amount), totals (invoice total, total VAT). It also adds required legal statements. If any field in your invoice is too long or contains unsupported characters, the generator may truncate or encode them appropriately. The module creates an XML text in UBL format following EU norms (which is basically an XML file that structured receivers can parse).

Download or Save:

After generation, the system will either prompt you to download the file or save it on the server and give a link. According to the code, it appears it saves the XML in an

uploads/xf_zatca/xml

path for ZATCA (thats Saudi, but for EU e-invoice, it likely similar logic places it in an e-invoice folder). For EU, it might directly download since those invoices arent stored long-term in system. If its a download, youll get a file named something like

E-Invoice_INV-1001.xml

(the code suggested it names it "E-Invoice - [InvoiceNumber].xml"). Save this file to your computer. This is the e-invoice.

Validation Check:

Its wise to validate the XML to ensure compliance (especially the first few times). There are online validators for UBL/EN16931. If the module is up-to-date, it should produce a valid file if all required data was provided. Quick check: open the XML file in a viewer. You should see your company name, the customer name, invoice totals, etc., in tags. If something obvious is missing or incorrect (like a missing buyer VAT), that might indicate missing input. You can correct the invoice in the system and regenerate the file if needed.

Delivering the E-Invoice

Via PEPPOL Network:

The main way to send e-invoices in EU is through the PEPPOL network (if both you and the recipient are registered participants with access points). If your company has a PEPPOL access point provider or e-invoicing service, you will upload or send this UBL XML to them for delivery. Some services let you email the XML to a specific address or upload via a portal; they then route it to the customers access point, and the customer receives it in their accounting system. Check with your IT or provider on how to actually transmit it. The E-Invoice modules job was to get you the file in correct format.

Via Government Portal:

Some countries (like Italys SdI or Frances Chorus Pro) require uploading invoices to a portal. In that case, log in to that portal and use the upload function, selecting the XML file. The portal will validate and forward it to the entity. Because the module prepared it to EU standard, it should pass portal checks, but portal might also require you to input additional metadata when uploading (like pick a department or confirm certain fields). Use the info from the invoice to fill any portal forms if asked.

Email or Other Methods:

If the customer allows, sometimes you might just email them the XML file (some small companies using e-invoice might accept that to import to their system). If doing so, accompany it with a note and possibly also attach the human-readable PDF invoice. Make sure to mention this is the structured invoice for automated processing. However, many government entities wont accept email they want it via network. So use the method specified by your client.

Ensuring Compliance and Record-Keeping

Record of Submission:

After sending the e-invoice, note it in your system. The module itself might not track whether you sent the XML; it just generates it. You can attach the XML file to the invoice record in the system for safekeeping either by uploading it as an attachment to that invoice (so you have a copy in case you need to refer to exactly what was sent). The systems invoice status can remain as Sent (same as any invoice). Maybe add an internal note like E-invoice XML sent via [method] on [date].

Monitor Acceptance:

Often with e-invoices to government, you receive statuses back (like accepted, or rejected with an error). Because our system is not fully integrated with those networks, you have to check on the portal or with your service if the invoice was accepted. If an e-invoice is rejected for some reason, correct the issue quickly (either adjust data and regenerate, or fix something on portal if it was a minor entry). Common causes might be mismatched PO numbers or an ID not recognized. The structured data helps pinpoint errors (like Buyer VAT ID invalid format etc.). After correction, resend and ensure its accepted.

Multiple Formats Support:

The module by default uses

PEPPOL UBL

format (which is widely accepted cross-EU). Some countries have local requirements: e.g., Italy requires FatturaPA (which is actually XML but slightly different fields). The code suggests it automatically picks CIUS-IT or CIUS-ES for Italy/Spain. If you have to comply with, say, French or German specifics, ensure the module covers those. If not, you might need to tweak output or use a conversion service. But generally, since 2020, the EU norm means the base format is consistent and the module likely adheres to it.

Archiving:

Keep copies of all e-invoices as you would normal invoices. In some countries, youre required to archive electronic invoices in their original format for a number of years (for audit). Storing them in a secure drive or as attachments in your system (with backups) suffices. The PDF is not the official invoice in these cases the XML is. So treat it as a legal document.

Updating Module:

E-invoicing standards can evolve (new code lists, etc.). Keep your system/module updated to the latest version to avoid falling out of compliance. For instance, new fields might be added over time (like recent changes for e-invoices to include banking info in structured form). Usually, the module developers update these. If you notice any compliance changes, check for an update or contact support.

Integration with Other Modules

Core Accounting:

The E-Invoice module doesn't change how invoices are recorded financially. It simply outputs an XML representation. When you mark an invoice as sent via e-invoice, treat it like a normal invoice in accounting the revenue is recorded already when the invoice was created. E-invoicing is about delivery, not additional posting.

ZATCA (if also using Middle East compliance):

The user specifically said ignore developer API and that, but just to note: this EU module is separate from the ZATCA (Saudi) module. You might use both if you invoice in EU and KSA. They work similarly in concept but produce different output (EU XML vs ZATCAs special QR and clearance). The system keeps them separate (as separate modules) so they dont conflict. Just ensure to use the correct function depending on invoice target. The UI likely clearly distinguishes (maybe separate menu items).

CRM/Sales:

From a sales process perspective, issuing an e-invoice doesnt change anything upstream in CRM or sales module except making sure clients have the needed fields as covered. Sales staff should be aware if a client requires e-invoices so they can alert accounting when a sale happens. Possibly add a flag in customer info like Requires E-invoice = Yes. Then when an invoice for them is created, youll know to run through this module. Could also incorporate a workflow where invoice generation for such clients automatically prompts e-invoice creation (if the system allowed hooking that in). But likely, it's a manual step after invoice approval.

Project/Contracts:

If your e-invoices relate to specific contracts or projects (commonly with government), make sure to include references like contract numbers in the invoice. The module puts a field for

Buyer Reference

which is often used for things like a Purchase Order number. In some EU e-invoices, the Buyer Reference might be a specific person or code the buyer gave you. Fill that field on the invoice (there is typically a field called Reference or Order Reference in the invoice entry screen) that will flow to the correct place in the XML. This ensures the clients system automatically matches the invoice to their PO or project.

By using the E-Invoicing (EU) module, you reduce manual data entry on your clients side and expedite payment cycles, while also

staying compliant with EU regulations

that increasingly mandate structured e-invoices. It professionalizes your billing for EU clients and avoids the risk of non-payment due to format issues. Always double-check the first few e-invoices to gain confidence, and after that, it should become a smooth, routine part of your invoicing workflow for applicable customers.

Screens & fields reference

Use these screens and fields to complete tasks inside E-Invoicing (EU) in XFatora.

Automations & notifications

Review automation rules and notifications available in E-Invoicing (EU) in XFatora.

Reports & dashboards

Track KPIs and dashboards powered by E-Invoicing (EU) in XFatora.

Common mistakes

• Skipping required configuration before the first workflow.
• Not assigning the correct permissions for team roles.
• Forgetting to review automation or notification settings.

FAQs

Troubleshooting

Related modules