XRechnung is structured XML; ZUGFeRD embeds the same data inside a PDF. Producing either is not technically hard. Doing it on every invoice, with the right fields, without breaking the route to accounting, is.
Being able to read an incoming e-invoice and being able to produce a correct outgoing one are two different jobs. Most companies get stuck on the receiving side first: a file arrives as an email attachment, someone carries it to accounting by hand, and the chain breaks there. The sending side depends on your ERP or order system handing over complete invoice data.
e-Rechnung Inbox produces ZUGFeRD and XRechnung from PDFs, scans and email. Processing happens in the Frankfurt region and hosting stays inside the EU. To be explicit: some of the cloud providers we use are US-headquartered companies even when the region is European. So we do not claim to avoid US services; we show which service runs in which region.
The moment an invoice is produced and the form in which it is stored belong to the same chain. If immutability, access logging and retention are not designed in, an archive added afterwards does not rescue the history. So we treat archiving as the first constraint when designing the flow, not the last step.
Usually not. In most cases it is enough to take the invoice data the ERP already provides, produce the correct format and hand it to accounting. Replacing an ERP is the most expensive and riskiest path; it only comes up when the invoice data is genuinely incomplete.
It depends on what the receiving side accepts. Public-sector buyers mostly expect XRechnung; for some commercial buyers ZUGFeRD is more practical because the same file is readable by both people and machines. Building the flow so it can produce both is cheaper than choosing once and revisiting it later.
Describe how you issue invoices today and how they reach accounting. We can usually name the break in the first conversation.