Telephone number used in XInvoice XML files

Hi,

I was trying out the E-Invoice feature of InvoiceNinja because I think we will have to use invoices according to the german ZUGFeRD specification in the future.
I selected XInvoice 3.0 as a format and created a new invoice.

When I download the E-invoice as an XML-File I can see that the telephone number used in the XML is the one of my InvoiceNinja user (that I use to login and create invoices).
The XML-element is:
... -> ram:ApplicableHeaderTradeAgreement -> ram:SellerTradeParty -> ram:DefinedTradeContact -> ram:TelephoneUniversalCommunication -> ram:CompleteNumber

But this is my cell phone number that I use for two-factor authentication, which we wouldn’t want present in the invoices we send to clients.

(I think the same happens when I use the format EN16931, but for some older formats the phone number is not present.)


Since I don't know which XML-format we will have to use, is there a possibility to change this behavior?

Can we specify which fields are used in the XML-file or where the information is taken from?

Hi,

@david can you please advise?

@plaschke

I can see that the primary user is configured as the main contact with that particular document spec.

I am pretty deep into einvoicing currently so I am slowly uncovering a lot of related issues in regards to property assignment.

@hillel it appears there are three levels of configuration needed for e invoices,

Some Company level property configuration
Some Client level property configuration
Some Entity level property configuration

The options to consider are:

  1. Being able to assign a Invoice Ninja property to the einvoice standard property
  2. Simply configuring an override per einvoice property

In the example described here, the user wishes to use a preferred phone number rather than hardcoded users.phone

To go a level deeper there appears to be a consistent issue with Einvoices at the client level:

Specifically related to addresses:

Romania, the city name cannot be used, but rather the matching Sector value, ie SECTOR1,2,3,4

Italy, the state name cannot be the full name ie Reggio Calabria but its 2 character equivalent these are two examples, i assume that there are many other similarities across standards that need to be catered at the client level. We would need to be able to either resolve these, or present an additional property that the user can explicitly assign.

At the invoice level, it may also be required that we force item taxes rather than total taxes as the einvoice standard may require the taxes at that particular location. At the invoice level there are also other important options that may be required, ie shipping details / date, contract dates codes etc etc.

1 Like

We created an xInvoice / xRechnung module for InvoiceNinja which is published here:

Maybe you could either check our module, or InvoiceNinja itself could adopt some of the configurations according to our module.

Best regards,

Boris

1 Like

Is there currently a possibility to change what data is used for the E-Invoice XML?
Or will this maybe be a feature in the future?

We want to use e.g. EN16931 as E-Invoice type and there we have the phone number of the user that created the invoice in the XML file. (some types contain this information, others don’t)

In the EN16931 XML:

  <rsm:SupplyChainTradeTransaction>
      <ram:ApplicableHeaderTradeAgreement>
      <ram:BuyerReference>No buyer's reference given</ram:BuyerReference>
      <ram:SellerTradeParty>
        <ram:Name>My Company Name</ram:Name>
        <ram:DefinedTradeContact>
          <ram:PersonName>Average Testuser</ram:PersonName>
          <ram:TelephoneUniversalCommunication>
            <ram:CompleteNumber>+43 123456789</ram:CompleteNumber>

On the production system this would be the private phone number that a user uses for 2FA. And we don’t want to have that in every invoice we send.

I think starting in 2025 we should issue invoices that conform to the German ZugFerd specification (at least for german clients). So we would like private user information to not be present in the E-invoice.

I think this is still work in progress, right?