remember customer fields for eRechnung

thgagel

Customer fields already filled out in eRechnung should be remembered for future entries for this customer (UStID, Leitweg-ID etc.).

SubTotal version: 1.5,62
Operating system: macOS
Device model: iMac Pro

timo

The main reason this isn't being done at the moment is that the database doesn't have fields to store this kind of information.

You can put the VAT ID and buyer reference (Leitweg-ID) into the clients address field, from where it will be parsed and pre-fill the e-invoice fields. Is there a specific reason this is not suitable for you?

What would you expect to happen if you write two invoices to the same client, but enter two different VAT IDs (for whatever reason)?

If the app stored this information, would it be sufficient if this information is being cached locally on your device (and not stored in the database), so when using the Cloud Sync, that informations would not be synced alongside the database?

thgagel

UStID is prone to misuse and should not be exposed if this is not absolutely necessary. And it is not an element of a ladungsfähige Adresse and may invalidate such an address.

The last entry wins (overwrites existing UStID and LeitwegID).

Ask yourself: "Would it be sufficient if something is not working as expected?" No.

timo

What do you mean with "should not be exposed"? Where is it exposed and to whom?
VAT IDs isn't secret information, you need to share it with your business partners and many companies are displaying it publicly on their websites.
I also don't understand what you mean with your second sentence, that it would invalidate an address.
You didn't respond to my question if storing this information locally (and not in the SubTotal database) would be sufficient. Would it? The fields could then auto-populate but reinstalling the app (or installing it on another device) would mean this information is cleared (until you re-enter it). This would be much easier to implement compared to adding fields for this to the SubTotal database schema

thgagel

What do you mean with "should not be exposed"? Where is it exposed and to whom?

Some valid reasons can be fount if searching for "UStID Missbrauch". It is exposed in the address field.

I also don't understand what you mean with your second sentence, that it would invalidate an address.

"Die ladungsfähige Anschrift bezeichnet in Gesetz, Rechtsprechung und juristischer Literatur einen Wohnsitz oder eine andere Anschrift (§ 68 Abs. 2 Satz 1 StPO), bei Unternehmern eine Geschäftsanschrift, nach Land, Ort, Postleitzahl und Straße, also eine Postanschrift, unter der eine Rechtspartei tatsächlich anzutreffen ist.
Die Angabe einer ladungsfähigen Anschrift wird im Rechtsverkehr in verschiedenen Zusammenhängen gefordert,..." (Wikipedia).
Additional elements in an address may invalidate its function as ladungsfähige Anschrift.

If the app stored this information, would it be sufficient if this information is being cached locally on your device (and not stored in the database), so when using the Cloud Sync, that informations would not be synced alongside the database?

This would be a cheap workaround. I would not participate in such a way of working. But well, if it solves my problem, you may do it so.

timo

thgagel Additional elements in an address may invalidate its function as ladungsfähige Anschrift

Where does it say that? It doesn't say that in the text you quoted.
Besides that, this feature request is about the customer address, but I think what you are referring to now is the "ladungsfähige Adresse" of the seller

thgagel This would be a cheap workaround. I would not participate in such a way of working

Can you elaborate why exactly you consider this a bad solution and what you would suggest otherwise?
Another idea I had was to always store the entire e-invoice XML along with the invoice in the database. But it would come with other drawbacks: It would increase the size of the database (especially in proportion to the current size). And what should happen hen the user changes parts of the invoice (e.g. the client name) or the "My company" details after creating an e-invoice? When re-creating the e-invoice (or create a new invoice with the same client), should it use the data from the stored e-invoice XML or use the current logic (e.g. parse VAT ID from client address field) to prefill values into the e-invoice dialog? Or should the app use one as the primary source and the other as a fallback?

thgagel

I referred to the "ladunsgfähige Adresse" of the customer. The "Zugang" of an invoice is relevant for the "Fälligkeit". Any additional information in a "ladungsfähige Adresse", that may introduce misunderstanding or cause errors will weaken or even invalidate the address and thus the "Zugang" and "Fälligkeit".
There are a lot of examples of addresses on the internet, that are not accepted by the Deutsche Post. Even placing of "Hausnummer" before the street name or using a comma in any address line may be a reason for a letter being rejected.

Instead of storing the complete XMLs, why not storing only the extra customer related fields entered in the E-Rechnung dialog? If these are synchonized between devices, this would be fine for me.

timo

Can you give any reference that shows that having the VAT ID showing on the same place as the customers address is invalid on an invoice? I have never heard of something like that before and I have received invoices from Apple that show VAT IDs in both customer and seller address. So you are saying Apple is doing it wrong?

thgagel Instead of storing the complete XMLs, why not storing only the extra customer related fields entered in the E-Rechnung dialog? If these are synchronized between devices, this would be fine for me

Because that would mean I'd had to add many more fields to the SQLite database schema instead of one (for the invoice XML). There are tons of "extra customer related fields", not just 3 or 4

thgagel

timo

As you say there are tons of "extra customer related fields". All of these cannot go into the address.

Maybe a JSON in a single text field could be an option for a varying amount of customer related fields. Basic configuration might be a list with fieldname -description, editing by user could be a dialog with fieldname fieldvalue and storage as JSON in a single text field in SQlite.

Rolf

Dear Timo! Congratulations to your excellent App. I recommended it to two friends in the last days and I think they have downloaded them already.

To the above mentioned topic I have a request. A governmental customer did send me a Purchase Order and the PO stated that the invoice needs to have filled out the fields:

BT-10 (Leitweg ID)
BT-13 (Bestellnummer)
It would be extremely helpful. These two entries can be made in the "E-Rechnung" dialog. But it seems that they will not be recorded in the invoice, which would be helpful for follow-on invoices.

In addition to that I would encourage you to think about:

BT-85 (Kontoinhaber/Name).
The reason for this is that - as everybody knows - since early October the IBAN is checked against the correct name of the account owner. If we would have the BT-85 filled out this helps al SubTotal users as the money runs very smooth into our bank account :-).

Looking forward to your thoughts!

Rolf

timo

Glad you like the app, thanks for recommening it.

Rolf But it seems that they will not be recorded in the invoice, which would be helpful for follow-on invoices.

What exactly do you mean with "will not e recorded in the invoice"? Are you referring to the PDF or e-invoice XML?
You can put any information in the free text field for the PDFs

Rolf The reason for this is that - as everybody knows - since early October the IBAN is checked against the correct name of the account owner

From what I know, this change only affects european users and as SubTotal targets users worldwide, I don't want to change anything in the main UI. But the e-invoice feature admittedly is for EU users, so I will consider making changes to accomodate for that.
I am considering adding the BT-85 to the "optional fields" in the e-invoice dialog (but leave it empty by default). Would this help? But before I do that, I'm interested in why exactly you need it. Does your account owner name differ from the company name that is already written into the e-invoice? Have you had problems already getting paid or are you only concerned this would be the case in the future?

Rolf

timo

Hi Timo,

Sorry if I could not make myself understandable. I try again!

BT-10 and BT-13:
When I export the ZUGFERD E-Invoice I have the possibility to integrate the BT-10 and BT-13 fields. However it seems that these fields are not saved so for follow-on invoices to the same projects I have to integrate the fields again. For Governmental Customers these fields are elemental as they guide the invoice to the persons who can accept the invoices. Therefore, it would be helpful if we can set these fields at a more prominent position.

BT-85
I did not have any bad experience by not getting paid so far. Of course, to add the BT-85 in optional fields would be a start. But then, I suspect, we would have the same issue like with BT-10 and BT-13, as this field is not saved and we have to write it in for each new invoice.

Please correct me if I'm wrong. I am a new user of your product!

Rolf

timo

fields in the e-invoice dialog are generally not saved across app sessions (this has been noted in other discussions here in the forum, e.g. here), BT-33 is an exception to this

BT-10: Can you give me examples of your BT-10 buyer reference? It should follow a standard format and be automatically recognized when you add it to the client address field

BT-13: This is "order number" - shouldn't it be different for each individual invoice or why should it be saved across sessions?

BT-85: I am planning to add BT-85 as an optional field in probably the next update and I plan to save the value across app sessions (like with BT-33)

Rolf

Dear Timo,

please excuse me with these special wishes. Again, your tool is great. I like that it is no overloaded and it is designed in the KISS-principle (keep it simple stupid). I am working 50% to governmental customers (B2G). They are driving the whole e-invoicing thing. And they are forcing their suppliers to be compliant with their rules. in the last 18 months more and more B2B customers introduced e-invoicing compliant processes. I assume in the next months more and more customers will ask (or force) their suppliers to switch to e-invoicing. B2G Customers force you to state certain BT-numbers. B2B can follow here. By December, 31st 2026 all businesses will have to provide BT-entries at their customers wish.

Here are my answers to your questions:

an BT-10 (Leitweg-ID) example is: 06-22500014-12
For Governmental Customers this field is mandatory. It guides the invoice to the right entity and person in the procurement system. BT-10 is connected to the Customer.

BT-13 (Auftragsnummer): I give you an example which I have quite often. A customer sends a purchase order which includes several line items. Every month you send the customer an invoice and you refer to the purchase order. Therefore you keep the BT-13 throughout the whole project. Projects can run several months and years under the same BT-13 which means many invoices are made to the same BT-13. Therefore it would be helpful if the BT-13 could be saved across the sessions. An example of such a number is: 4501414292.

BT-85: this would be great!

Please find attached two documents which might provide some helpful information.
https://e-rechnung-bund.de/app/uploads/2025/09/Broschuere-fuer-Rechnungssteller_092025.pdf
--> Page 8 describes mandatory fields

https://e-rechnung-bund.de/app/uploads/2025/09/Uebersichtsliste-Eingabefelder-OZG-RE_092025.pdf
--> gives an overview of all BT-fields.

With kind regards,

Rolf