Sales Pack - XInvoice

[Bernhard]

From 2025 on, every B2B invoice needs to use a digital format (in Germany, other EU countries are already using this or will need to use it later).
Digital does not just mean a PDF version of the invoice. This means that an XML part with officially defined fields needs to be included in the PDF, or that PDF is even not required anymore.

Small companies may need to migrate to the XInvoice format later, but this is the way of future B2B invoicing.

Although there is still some time until 2025, I would like to ask about the possibilities of integrating XInvoices into the Sales Pack.

Thanks,


Bernhard

[yuri]

Hi Bernhard,

I searched on the internet quickly, and didn't find a lot of info. Googled with some popular ERPs, invoicing apps in a search query. Could you provide more info on it?

[novastream]

I haven't heard about Xinvoice but I'm helping a lot of companies that are using Edifact D96A and PEPPOL and usally this do not fall under the CRM/ERP. Usually you use an external partner to convert you invoices via API or by uploading XML/JSON files to the integration partner and they do the converting and sending of the invoice.

[Bernhard]

I think that's a good option if the process can be included in the Salespack workflow. So, adding a button next to Print to PDF does the job. Thanks for your input.

[item]

Hi,
i have diffictult with english but :

https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing

And there are a library @MIT

https://github.com/josemmo/einvoicing

Hope this can help and if i have good understand

[yuri]

One more project that may be useful https://github.com/easybill/zugferd-php.

[Bernhard]

Hi, thanks for the links. I think they are going in the right direction.

This is one system supporting the new invoices: https://einfach-xrechnung.de/en/

I find many German websites about that, but not so many English sites. In Germany at least this is called xRechnung. Other places use eInvoice, but it needs to be the same standard. One type is also called zugFeRD - I think its a german initiative but goes into the same direction: https://www.billwerk.plus/wiki/standards-norms/zugferd-format/#:~:text=Simply%20explained%2C%20a%20ZUGFeRD%2Dcom patible,automated%20processing%20with%20the%20XML.

My best guess is, that there will be possible multiple xml templates and a solution where templates can be adjusted would have less problems if things change ...

item, thanks for linking the GitHub Library. I think this sounds great.

Thanks for checking this.

[mwo300]

what Bernhard means is probably this:

I had some recent contact with it. Basically when you creating an invoice in a PDF form, you are not simply printing it visually, but also create an XML Structure with it that has a specific format. Currently it's mainly used when working with official state departments within Germany.

I don't know how that will work in B2B with small companies, but what you may want to look at is this:

en16931 · PyPI

[hom]

Hello everyone,

I would also very much welcome an integration of the XML invoice in the EspoCRM sales pack.

As Bernhard has already written, this standard will be mandatory in Germany from 2025, and later probably throughout the EU. As this is intended to combat tax evasion, it can also be assumed that the xml invoice will remain. In contrast to some other digitization projects

As far as I can see, there are standards for Germany (X-Rechnung) and France (Factur-X). Both standards are included in the ZuGFerd standard 2.2. This may offer a good approach for implementation. The advantage of the ZuGFerd standard is that a PDF invoice with an integrated XML invoice is generated.

Why does it make sense to combine PDF and xml invoices?
The obligation to use XML invoices initially only applies to the B2B sector. Invoices to private individuals or amounts up to EUR 250 are not subject to the xml invoice obligation. The xml obligation also does not (yet) apply to cross-border invoices either.

However, as EspoCRM is intended to be flexible all areas can be covered with that. Here is the link to the ZuGFerd standard: https://www.ferd-net.de/standards/zu...2.2/index.html

So it would be great if the option for xml invoicing could be included in the sales pack. As invoicing from EspoCRM works excellent so far, it would almost be a disaster to use a different program here.
You are welcome to contact me for tests.
Regards
Holger

[yuri]

Hi,

The question whether the PDF and XML have to be separate or somehow combined (XML in PDF?). Is there any implementation among other popular ERP/CRM systems?

EDIT. It looks that the "ZUGFeRD" defines combination of XML and PDF. The problem is implementation. We use Dompdf lib, not sure it does support it. It does not support PDF/A mode yet. Haven't yet researched deeply.

May be useful: https://github.com/atgp/factur-x

[item]

Hi,
maybe here we understand more (it's my case )

https://www.mustangproject.org/

At the right you see a sample PDF containing Factur-X/ZUGFeRD metadata generated with the Mustang library. If you open it in Adobe Acrobat Reader just click on the paperclip symbol to see the embedded ZUGFeRD XML structure. It has been created using the invoice class. Which you can also use to create a XRechnung.

So for dompdf.. maybe insert xml in a comment tag <!-- {{xml}} -->

Maybe.

[radek]

Hello,

in Czech Republic we have ISDOC format which is XML file that is usally sent alongside invoice (invoice.isdoc), or directly embeddedinto PDF as some PDF attachments.

Here is a github repo with code sample https://github.com/isdoc/isdoc.pdf

There is also documentation available, but it's in Czech https://isdoc.cz/6.0.2/doc/isdoc.html

Since we had to do multiple XML exports for various accounting software we also made a module for XML templates which work the same as PDF templates, but instead of printing to PDF it will save as XML file (while the same handlerbars and template helpers are available) - this could possibly be a good approach for this too, since clients may need to make small adjustments to the XML files. From my experience it's impossible to cover all types of clients, some are in OSS (one stop shop) some are "special vat payers or something" and XML templates do add a lot of flexibility to this, since you can use if statements, template helpers etc.

[peterberlin]

Maybe the link will help:

https://www.e-rechnung-bund.de/faq/

https://www.e-rechnung-bund.de/faq/x...hen%20Rechnung.

According to the GOBD, EspoCRM is not suitable for generating invoices in Germany.
peter

[yuri]

> EspoCRM is not suitable for generating invoices in Germany.

Maybe still suitable as it's not yet 2025.

[yuri]

There's some movement in Dompdf into supporting PDF/A. That's good news for us.

[yuri]

I have some questions which are important for the future implementation. Will appreciate if anybody with experience could answer.

1. Would we need the ability to export the same invoice in different formats? When one format is needed for a customer, another – for our company. For example, XRechnung and RO_CIUS.

2. Would we need the ability to export different invoices in different formats? For example, one invoice for Romanian customer in their regional format/standard, another invoice – in German format.

Thanks

[shalmaxb]

As far as I understand, there are general European rules, complemented with some countrywise rules. The Link from peterberlin provides the german version, but there is an english verson for developers: https://en.e-rechnung-bund.de/e-invo...are-companies/
I am not able to judge all this, but perhaps it could help you yuri .

[yuri]

There's a general EN 16931 standard that is extendable by design. Different countries have different standards upon that basic once. Usually, it's additional validation rules or more restrictive rules. The e-invoice should also contain the specification identifier.

I consider an international (Europe only for now) solution, not only German/France specific.