Fattura elettronica ZUGFeRD da un elenco di SharePoint: converti JSON in XML EN 16931 e PDF/A-3 in Power Automate con PDF4me

PDF4me Create ZUGFeRD Invoice è un'azione di Power Automate che trasforma i dati di una fattura in una fattura elettronica ibrida PDF/A-3. Puntata a un elenco di SharePoint, l'azione prende il JSON generato da un'azione Compose da ogni riga, scrive autonomamente il file XML conforme EN 16931, disegna la fattura leggibile sul PDF di base, archivia il risultato e lo invia via e-mail all'acquirente.
Cercando ZUGFeRD ci si imbatte in una di queste tre soluzioni: una spiegazione del formato, un validatore che verifica la correttezza di un file già in possesso, oppure una libreria in PHP, Java o C# per sviluppatori di software di fatturazione. Tutte e tre presuppongono che la fattura esista già da qualche parte. La domanda a cui nessuna di queste soluzioni risponde è quella che un team finanziario si pone realmente: i dati della fattura si trovano in un elenco, in un foglio di calcolo, in qualsiasi sistema registri le vendite, e devono essere elaborati come fattura elettronica conforme. Questo flusso rappresenta proprio quel passaggio intermedio mancante, in sette fasi e senza bisogno di scrivere codice.
Una riga viene inserita in un elenco di SharePoint con il venditore, l'acquirente, una voce e le date. Quattro secondi dopo, in una raccolta documenti, si trova una fattura PDF/A-3: una pagina leggibile, con il codice XML EN 16931 incorporato, che il software dell'acquirente può elaborare. Non è necessario scrivere manualmente il codice XML. La fattura viene descritta come un breve oggetto JSON e PDF4me genera automaticamente lo schema. La riga riceve lo stato e un link, e l'acquirente riceve il file via e-mail.
Domande e risposte basate sul perché
Perché conservare i dati delle fatture in un elenco di SharePoint? Perché questo è il formato in cui i dati sono già presenti nella maggior parte dei piccoli team finanziari: una riga per ogni fattura, compilata da una persona. Le colonne corrispondono uno a uno ai campi richiesti dallo standard, il che significa che la corrispondenza è visibile a chiunque apra l'elenco e una nuova fattura corrisponde a una nuova riga anziché a un nuovo file in una cartella monitorata.
Perché descrivere la fattura in formato JSON invece di scrivere in XML? Perché la sintassi Cross Industry Invoice è prolissa e rigida: namespace annidati, nomi di elementi che nessuno ricorda, codici che devono essere posizionati esattamente nel punto giusto. L'oggetto JSON esprime la stessa informazione in una frazione delle righe, con chiavi che corrispondono ai termini commerciali che rappresentano. PDF4me lo converte nello schema, quindi la parte in cui è più facile commettere errori è quella che non devi gestire.
Perché generare la fattura su un PDF di base? Perché un file ZUGFeRD è composto da due parti che devono essere coerenti. Il file XML è destinato al software dell'acquirente, mentre la pagina stampata è per chi la apre. Render Invoice on PDF disegna la fattura sulla pagina di base utilizzando gli stessi dati che hanno generato il file XML, in modo che le due parti non possano mai differire, come accade quando il layout viene gestito separatamente.
Perché PDF/A-3 e non un normale PDF? Perché PDF/A-3 è il formato di archiviazione che consente di allegare file, e l'XML incorporato rappresenta proprio quell'allegato. È anche la parte che rende la fattura leggibile anche a distanza di anni: i caratteri e i profili colore vengono mantenuti all'interno del file, un aspetto fondamentale per un documento che la maggior parte delle aziende è tenuta a conservare per un decennio.
Cosa riceverai
Input: una riga con il numero di fattura, le date, la valuta, il blocco venditore, il blocco acquirente e una voce. Output: una fattura ZUGFeRD PDF/A-3 nella libreria ZUGFeRD Invoices, la riga aggiornata con il suo stato e un link, e un'e-mail all'acquirente con la fattura in allegato.

Una riga per fattura. Ogni colonna in questo riquadro diventa una chiave nel JSON generato dal flusso.

Un file per ogni numero di fattura, scritto dal conto di flusso.

La metà leggibile dello stesso file, così come la vede l'acquirente.
Di cosa hai bisogno
- Power Automate. Apri Power Automate. Un flusso cloud automatizzato su connettori standard. SharePoint, Office 365 Outlook e PDF4me non richiedono un piano premium.
- Chiave API di PDF4me. Ottieni la tua chiave API. Questo flusso utilizza una connessione PDF4me, PDF4me PDF.
- Un elenco di SharePoint per le richieste. L'elenco acquisito si chiama ZUGFeRD Requests e include i InvoiceNumber, InvoiceDate, DueDate, Valuta, il blocco Seller (nome, via, codice postale, città, paese, ID IVA), il blocco Buyer, ItemDescription, Quantità, UnitPrice, VATRate, una colonna Email, una colonna di scelta Status e una colonna OutputLink in cui il flusso scrive.
- Un PDF di base per la fattura. Il flusso acquisito mantiene
BaseInvoice.pdfin una libreria chiamata ZUGFeRD Templates. Questa è la pagina su cui viene disegnata la fattura, quindi la tua intestazione va inserita qui. - Una libreria per le fatture finali. Il flusso acquisito scrive in ZUGFeRD Invoices.
- I tuoi dati di venditore, incluso il ID IVA. Questi dati vanno inseriti nelle colonne dell'elenco, in modo che lo stesso flusso possa emettere fatture per più di un'entità legale.
Il flusso in sintesi
- When an item is created (SharePoint), viene monitorata la lista denominata
ZUGFeRD Requests. - Compose crea il JSON della fattura a partire dalla riga.
- Get file content using path
/ZUGFeRD Templates/BaseInvoice.pdf. - Create ZUGFeRD Invoice (PDF4me PDF) converte il JSON in XML EN 16931 e restituisce il PDF ibrido.
- Create file (SharePoint) e salvalo come
ZUGFeRD_<invoice number>.pdf. - Update item (SharePoint) imposta Status su
Generatede compila OutputLink. - Send an email (V2) (Office 365 Outlook) invia la fattura all'acquirente.
Panoramica completa del flusso

Quattro secondi e qualcosa dall'inizio alla fine, e la fattura elettronica in sé richiede circa un secondo. La fase più lenta è la scrittura del file da parte di SharePoint.
Passaggio 1: Come si fa a generare una fattura elettronica al ricevimento di una richiesta?
Flusso finora: ancora niente, questo è il trigger.
L'aggiunta di una riga è il modo in cui viene richiesta una fattura, quindi questo è il segnale.
- Crea un Automated cloud flow e seleziona SharePoint > When an item is created.
- Configura:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests
- Site Address:
When an item is created: configurazione

Ogni colonna della nuova riga diventa un token che le successive sei azioni potranno utilizzare.
Passaggio 2: Come si crea il file JSON della fattura a partire dalle colonne dell'elenco?
Flusso finora: il trigger di SharePoint.
Un'azione Compose descrive l'intera fattura. Qui i nomi delle colonne corrispondono ai nomi previsti dallo standard e il tutto è sufficientemente breve da poter essere letto su una sola schermata.
- Aggiungi Data Operation > Compose.
- Incolla l'oggetto sottostante nel campo Input e sostituisci ogni valore con il token corrispondente.
{
"InvoiceId": "@{triggerBody()?['InvoiceNumber']}",
"TypeCode": "380",
"InvoiceType": "RECHNUNG",
"IssueDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"DeliveryDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"IsTest": false,
"Seller": {
"Name": "@{triggerBody()?['SellerName']}",
"VatId": "@{triggerBody()?['SellerVATID']}",
"Address": {
"Street": "@{triggerBody()?['SellerStreet']}",
"PostalCode": "@{triggerBody()?['SellerPostalCode']}",
"City": "@{triggerBody()?['SellerCity']}",
"Country": "@{triggerBody()?['SellerCountry']}"
}
},
"Buyer": {
"Name": "@{triggerBody()?['BuyerName']}",
"Address": {
"Street": "@{triggerBody()?['BuyerStreet']}",
"PostalCode": "@{triggerBody()?['BuyerPostalCode']}",
"City": "@{triggerBody()?['BuyerCity']}",
"Country": "@{triggerBody()?['BuyerCountry']}"
}
},
"LineItems": [
{
"ProductName": "@{triggerBody()?['ItemDescription']}",
"Quantity": @{triggerBody()?['Quantity']},
"UnitCode": "C62",
"UnitPrice": @{triggerBody()?['UnitPrice']},
"LineTotal": @{float(...)}
}
],
"Totals": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"LineTotal": @{float(...)},
"TaxBasisTotal": @{float(...)},
"TaxPercent": @{triggerBody()?['VATRate']},
"TaxTotal": @{float(...)},
"GrandTotal": @{float(...)},
"ChargeTotal": 0,
"AllowanceTotal": 0
},
"Payment": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"PaymentReference": "@{triggerBody()?['InvoiceNumber']}",
"DueDate": "@{triggerBody()?['DueDate']}T00:00:00"
}
}
Compose: configurazione

I valori testuali sono token racchiusi tra virgolette. Il denaro e le quantità sono numeri semplici, motivo per cui vengono elaborati tramite float.
Da dove proviene ciascuna parte della fattura
| Chiave JSON | Cosa trasporta | Fonte |
|---|---|---|
InvoiceId, TypeCode, InvoiceType | Numero di fattura, codice tipo documento 380 per fattura commerciale e etichetta stampata sulla pagina | InvoiceNumber, quindi valori fissi |
IssueDate, DeliveryDate | Quando è stata emessa la fattura e quando è stato erogato il servizio | InvoiceDate, con suffisso T00:00:00 |
Seller | Nome, ID IVA e indirizzo completo | SellerName, SellerVATID, SellerStreet, SellerPostalCode, SellerCity, SellerCountry |
Buyer | Nome e indirizzo del cliente | BuyerName, BuyerStreet, BuyerPostalCode, BuyerCity, BuyerCountry |
LineItems | Descrizione, quantità con codice unità C62, prezzo unitario e totale della riga | ItemDescription, Quantità, UnitPrice |
Totals | Valuta, totale netto, base imponibile, aliquota e importo IVA, totale complessivo | Valuta, VATRate e importi calcolati |
Payment | la valuta, il riferimento che l'acquirente indica al momento del pagamento e la data di scadenza | Valuta, InvoiceNumber, DueDate |
Suggerimento. Le chiavi relative al denaro sono l'unica parte che richiede calcoli aritmetici e devono risultare come numeri semplici anziché come stringhe racchiuse tra virgolette, per le quali esistono le espressioni float. LineTotal è la quantità moltiplicata per il prezzo unitario, TaxBasisTotal è la somma dei totali di riga, TaxTotal è la base imponibile moltiplicata per l'aliquota divisa per 100 e GrandTotal è la somma dei due valori. Per la riga acquisita, i valori sono 1005, 1005, 190,95 e 1195,95. Un "1005" racchiuso tra virgolette verrà rifiutato, mentre un semplice 1005 è accettato.
Passaggio 3: Da dove proviene il PDF di base?
Flusso finora: il trigger più Compose.
I file ZUGFeRD hanno una pagina leggibile, ed è da qui che inizia.
- Aggiungi SharePoint > Get file content using path.
- Configura:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - File Path:
/ZUGFeRD Templates/BaseInvoice.pdf - Infer content type (avanzato):
Yes
- Site Address:
Get file content using path: configurazione

Conserva la tua carta intestata in questo file. Viene letta di nuovo a ogni ciclo di fatturazione, quindi modificarla influirà sulla fattura successiva.
Passaggio 4: Come si converte un file JSON in un PDF/A-3 ZUGFeRD?
Flusso finora: il trigger, Compose e Get file content using path.
Questa è l'azione che genera la fattura elettronica. Legge il file JSON, genera autonomamente il file XML conforme EN 16931 e restituisce un unico file contenente entrambe le parti della fattura.
- Aggiungi Create ZUGFeRD Invoice dalla connessione PDF4me PDF.
- Configura:
- ZUGFeRD version and Input Format:
2.0-JSON - Output Mode:
XmlWithPdf - Invoice JSON Data: l'espressione
base64(outputs('Compose')) - Conformance Level:
EN16931 - Render Invoice on PDF:
Yes - File Content: un'espressione
base64()sul contenuto da Get file content using path - File Name:
BaseInvoice.pdf
- ZUGFeRD version and Input Format:
Create ZUGFeRD Invoice: configurazione

Il formato di input determina quale campo dati viene visualizzato. Selezionando 2.0-JSON, l'azione richiederà Invoice JSON Data, non Invoice XML Data.
Ciò che decide ogni impostazione
| Campo | Valore qui | Ciò che controlla |
|---|---|---|
| ZUGFeRD version and Input Format | 2.0-JSON | Quale generazione ZUGFeRD segue l'output e che i dati arrivino in formato JSON. Questa scelta è ciò che fa apparire il campo Invoice JSON Data |
| Output Mode | XmlWithPdf | Restituisci un file ibrido, ovvero il PDF con l'XML incorporato, anziché il solo XML |
| Invoice JSON Data | base64(outputs('Compose')) | L'oggetto fattura, codificato base64 durante l'inserimento |
| Conformance Level | EN16931 | Il profilo che la fattura dichiara di soddisfare e quindi quali chiavi deve fornire il JSON |
| Render Invoice on PDF | Yes | Disegna la fattura leggibile sul PDF di base invece di lasciare la pagina così com'era |
| File Content, File Name | Il PDF di base | La pagina su cui è disegnata la fattura e il nome a cui l'azione fa riferimento |
Suggerimento. L'azione mostra Invoice XML Data, Invoice JSON Data o Invoice CSV Data a seconda della sezione Formato del menu a tendina. Compila solo il campo corrispondente alla tua scelta. Inserire due campi dati nella stessa esecuzione è la causa più comune di errori di convalida in questa azione.
Passaggio 5: Dove va archiviata la fattura?
Flusso finora: tutto tramite Create ZUGFeRD Invoice.
Il numero di fattura identifica il file, consentendo così di effettuare ricerche nella libreria.
- Aggiungi SharePoint > Create file.
- Configura:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - Folder Path:
/ZUGFeRD Invoices - File Name:
ZUGFeRD_seguito dal token InvoiceNumber e dall'estensione.pdf - File Content: il token Body da Create ZUGFeRD Invoice
- Site Address:
Create file: configurazione

Per RE-2026-0007 viene scritto ZUGFeRD_RE-2026-0007.pdf.
Passaggio 6: Come si registra il risultato della richiesta?
Flusso finora: tutto tramite Create file.
Nella riga in cui si richiede la fattura dovrebbe essere specificato anche cosa ne è stato.
- Aggiungi SharePoint > Update item.
- Configura:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests - Id: il token ID del trigger
- Title: il token Title dal trigger
- Status Value (avanzato):
Generated - OutputLink (avanzato): l'URL della libreria seguito da
ZUGFeRD_, il token InvoiceNumber e.pdf
- Site Address:
Update item: configurazione

Il collegamento viene creato a partire dall'URL della libreria e dallo stesso modello di nome Create file utilizzato, con lo spazio nel nome della libreria già codificato come %20.
Passaggio 7: Come si invia la fattura all'acquirente?
Flusso finora: tutto tramite Update item.
Una fattura elettronica che rimane in una libreria non è stata emessa, quindi l'ultima azione ne determina la consegna.
- Aggiungi Office 365 Outlook > Send an email (V2).
- Configura:
- A: il token Email dal trigger
- Oggetto:
Your ZUGFeRD e-invoiceseguita dal token InvoiceNumber - Body: una riga che indica l'acquirente e la fattura, e specifica che il file è un PDF/A-3 con XML EN 16931 incorporato
- Apri Advanced parameters e aggiungi l'allegato:
- Nome Attachments - 1:
ZUGFeRD_più il token InvoiceNumber più.pdf - Contenuto Attachments - 1: il token File Content da Create ZUGFeRD Invoice
- Importance:
Normal
- Nome Attachments - 1:
Send an email (V2): configurazione

L'allegato prende i suoi byte dall'azione che lo ha generato, quindi SharePoint non li legge mai.
Esegui il flusso e verifica
- Save il flusso.
- Aggiungi una riga alle ZUGFeRD Requests con un acquirente, una voce, entrambe le date e un indirizzo che puoi verificare.
- Apri la cronologia delle esecuzioni. Tutte e sette le azioni dovrebbero essere verdi e l'intera esecuzione dovrebbe durare pochi secondi.
- Apri la libreria ZUGFeRD Invoices e verifica che il file sia presente con il numero di fattura corrispondente.
- Torna alla riga: Status dovrebbe essere Generated e OutputLink dovrebbe aprire la fattura.
- Apri l'allegato dell'email e controlla entrambe le parti: la pagina dovrebbe mostrare gli importi corretti e il file dovrebbe contenere al suo interno il codice XML.
L'esecuzione del processo ha richiesto circa quattro secondi in totale, di cui uno dedicato alla generazione della fattura elettronica. Il risultato, ZUGFeRD_RE-2026-0007.pdf, ha una dimensione di circa 331 KB e si presenta come una fattura tedesca: venditore Muster GmbH di Berlin con ID IVA DE123456789, cliente Test Kunde AG di Muenchen, tipo di documento 380, una riga relativa alla Consulting con IVA al 19%, importo netto 1.005,00 EUR, IVA 190,95 EUR e un totale di 1.195,95 EUR.
Cosa hai effettivamente realizzato? Un sistema di fatturazione elettronica che parte dai tuoi archivi. I dati rimangono dove li conserva il reparto finanziario, lo standard è rispettato grazie a un file XML che non hai mai dovuto scrivere, l'acquirente riceve un file che il suo software può leggere automaticamente e il suo personale può visualizzarlo a schermo, e la riga della richiesta registra l'avvenuta emissione.
Varianti comuni che puoi aggiungere senza dover ricostruire
Come si confronta questo con gli altri metodi di emissione di una fattura ZUGFeRD
Ogni riga descrive l'alternativa. L'ultima riga rappresenta questo flusso.
| Confronto | Chi lo gestisce? | Da dove provengono i dati | Ciò che mantieni |
|---|---|---|---|
| Software di fatturazione con esportazione ZUGFeRD vs questo flusso | Chiunque, all'interno di quel prodotto | I dati propri del prodotto | Un abbonamento e tutto ciò che il prodotto supporta |
| Piattaforma di fatturazione elettronica vs questo flusso | Finanza, attraverso un portale | Caricamenti o un'integrazione | Un contratto per documento e una connessione ad esso |
| Libreria per sviluppatori vs questo flusso | Uno sviluppatore, all'interno di un'applicazione | Il tuo database, tramite codice | Il codice, gli aggiornamenti dello schema e le release |
| Questo flusso | Chiunque può aggiungere una riga di elenco | Un elenco SharePoint che il team tiene | Un oggetto JSON e un PDF di base |
Domande frequenti
Che cos'è una fattura ZUGFeRD?
Una fattura ZUGFeRD è un singolo file che funziona in due modi. È un normale PDF che può essere aperto e letto, e al suo interno si trova un allegato XML contenente la stessa fattura come dati strutturati. Il sistema contabile dell'acquirente legge l'XML e registra la fattura senza che nessuno debba inserirla manualmente, mentre l'addetto alla contabilità fornitori continua a visualizzare la pagina.
Il formato proviene da FeRD, il forum tedesco per la fatturazione elettronica, e la sua controparte francese è Factur-X, che è la stessa idea con un nome diverso.
Cos'è il formato ZUGFeRD?
Tecnicamente si tratta di un contenitore PDF/A-3 con un file XML incorporato nella sintassi Cross Industry Invoice e un profilo che indica il livello di completezza dei dati. Il profilo utilizzato in questo caso è EN16931, che corrisponde allo standard semantico europeo per la fatturazione elettronica: l'insieme di campi che EN 16931 definisce come il nucleo di una fattura.
La conseguenza pratica per un'automazione è che l'output viene valutato in base al file XML, non alla pagina. Se si forniscono i dati richiesti dal profilo, il file viene accettato; se si migliora l'aspetto della pagina, non cambia nulla.
Come creare una fattura ZUGFeRD?
Ti servono tre cose: i dati della fattura in un formato strutturato, una pagina per la parte umana e un programma che scriva l'XML nel PDF come allegato PDF/A-3.
In questo flusso, i dati sono una riga di SharePoint convertita in JSON, la pagina è BaseInvoice.pdf e Create ZUGFeRD Invoice si occupa della terza parte con Output Mode XmlWithPdf. Se i dati esistono già come file XML Cross Industry Invoice o come riga CSV, è sufficiente modificare il formato di input e utilizzare quello. Il resto del flusso rimane invariato.
Qual è la differenza tra ZUGFeRD e XRechnung?
Entrambi soddisfano lo stesso standard europeo, la differenza sta nel formato. ZUGFeRD è un formato ibrido: un PDF leggibile con l'XML al suo interno, adatto alle fatture inviate ai clienti che potrebbero aprirle manualmente. XRechnung è invece un formato esclusivamente XML ed è quello richiesto dagli enti pubblici tedeschi.
Se inviate documenti ad aziende, il formato ibrido è generalmente la scelta più sicura, perché è leggibile da chiunque lo apra. Se invece emettete una fattura a un ente pubblico, verificate quale formato è richiesto da tale ente prima di inviare la fattura.
Risoluzione dei problemi
Apri l'output Compose nella cronologia delle esecuzioni e leggilo come JSON prima di qualsiasi altra cosa. Una colonna vuota lascia una chiave vuota e un valore monetario che ha mantenuto le virgolette viene visualizzato come testo dove è previsto un numero. Entrambi producono un oggetto che sembra corretto ma la conversione fallisce comunque.
Conformance Level determina quali campi sono richiesti dal profilo. Dichiarare la conformità EN16931 quando il JSON omette le chiavi previste dal profilo comporterà l'errore di convalida, anche se il file si apre normalmente. È necessario fornire le chiavi mancanti o passare a un profilo di livello inferiore.
Render Invoice on PDF è impostata su No, quindi l'XML è stato incorporato senza visualizzare nulla. Il file è comunque una fattura elettronica valida, ma la parte relativa all'utente corrisponde al contenuto del PDF di base.
Verifica il contenuto dell'allegato nella fase di invio dell'e-mail e il File Content in Create file. Entrambi devono provenire da Create ZUGFeRD Invoice. Allegare il PDF di base, invece, invia una pagina che sembra corretta ma non contiene nulla che il loro software possa leggere.
Prossimi passi
Lo stesso schema in sette fasi (arriva una riga, una fattura viene descritta come dato, viene prodotto un file, archiviato, registrato e inviato) è ciò che in realtà richiede ogni mandato di fatturazione elettronica, indipendentemente dal formato di cui i vostri acquirenti avranno bisogno.