Implementation of ZUGFeRD and xRechnung for german Users

[mamo2021]

Hello,
I would like to point out that there are plans in Germany to only recognize invoices in the B2B sector in structured electronic form from 2025. Conformity with future invoices has already been confirmed for the xRechnung and ZUGFeRD formats (from version 2.0.1). Although the legal basis ("Wachstumsbeschleunigungsgesetz") has not yet been finally adopted, it can be assumed that this legal requirement for future invoicing in the business sector will be introduced.
If Invocie-Ninja is then unable to meet these requirements, the application will become useless for all users operating in the B2B sector.

Invoicing in accordance with the ZUGFeRD standard will presumably be the variant that is accepted by most users, as a PDF with the document image is available in addition to the required structured data record. The xRechnung, on the other hand, does without the document image and only provides the structured data. It will therefore make sense to implement the ZUGFeRD standard first if the further use of the software in Germany is also intended in the business environment.

Regards

[turbo124]

We already support this.

[turbo124]

its not documented - but it works, just select the e-invoice standard you need in Settings > Email settings. (Enable E-Invoice)

[georgkaser]

Fantastic - I will try it, thank you!

[georgkaser]

Cool! - Can you tell me, where is this documented? I came across because next year it will be obligatory to send invoices in XRechnung format.

[turbo124]

Settings > email settings - enable e-invoice

Then change to the e-invoice type required.

Afterwards from the invoice page, we will embed the XML into the .pdf as an embeded attachment - or you can download the .xml direct using the menu action:

[elvirdz]

Its not Perfect IBAN should be in XML what we get is
ram:InformationDie Rechnung muss online über den bereitgestellten Link bezahlt werden</ram:Information>

I saw Invoice Ninja xRechnung as Plugin, but I think it will be possible

[turbo124]

@elvirdz are you saying the IBAN needs to be included?

[elvirdz]

I thnik so look at https://xrechnungsgenerator.nortal.com/

[LarsK1]

@turbo124 I think it would make most sense to move the e-invoicing to a own section in the settings and to create a set of settings for payment, delivery, fees, etc. ...

So that every aspect can be used. We will also have to implement credit and cancellation notes.

[turbo124]

@LarsK1 I agree, let me know how you see this working... i would image a series of toggles for users to curate the output they would like to see. from each type of document

[LarsK1]

@turbo124 here's my idea. Since the e-invoicing is getting much more requested and even required from the european goverment starting at 2025, we split the e-invoicing to a new tab. This would need the following sections: quote / invoice / cancellation / credit.

In these we need a lot of items. I'll start a list here: (maybe other users can add ideas to it as well.)

• payment options (multiselect dropdown with credit card, sepa, bank transfer, ...)
• payment terms / allowance information
• payment details (according to the selection of the payment options)
• allowance information

On top we need further fields in the customer / invoice:

• payment instructions (could be in the general part of the selling company as well)
• contract reference (maybe more useful in the projects?)

Let me know, what you think

[turbo124]

@LarsK1

I've been looking into this extensively. The range of options inside of e-invoicing is so expansive the only way to handle this would be a dedicated settings section.

My current thinking would be an interface that allows a user to curate the fields that are to be included in the e-invoice. We would also need to provide a mapping section where the user could reference the e-invoice field and the invoice ninja property to associate it with. If none were available, we would need to extend the schema somehow... (my current thinking is an object column on the invoice itself and potentially client/company tables) where a user can associate a e-invoice field with a new property on these models and using the XSD files we can associate the correct type required for this field.

ie. ContractReference => new Prop Invoice.einvoice.contract_reference prop

Looking at the Spanish / Romanian / Italian and German-Franco implementations, they vary quiet a bit, so there is no single way that we can extend the database alone in a sane way to cope with the additonal fields.

[LarsK1]

@turbo124 yep,
this sounds pretty straight forward. Especially since we currently don't know, in which way these standards might develop.