E-Invoice: Documentation
Ninox E-Invoice Documentation
Electronic invoicing is becoming an important part of business operations in Germany and across Europe.
From 2025, Germany will make e-invoicing mandatory for B2B transactions, following the lead of other EU countries that have introduced similar regulations. This shift towards the digitization of invoicing processes is intended to increase efficiency, transparency and compliance while reducing tax fraud.
To comply with these new regulations, companies must implement compliant e-invoicing systems that can create, send and receive electronic invoices in structured formats such as XML or UBL.
Structure
General
1. General Overview of E-Invoicing
E-Invoicing is set to become an essential part of business operations in Germany and across Europe.
Starting in 2025, Germany will enforce mandatory e-invoicing for B2B transactions, similar to other EU countries that have already implemented comparable regulations. This shift toward digitizing invoice processes aims to enhance efficiency, transparency, and compliance while simultaneously reducing tax fraud.
To comply with these new regulations, companies will need to implement compliant e-invoicing systems capable of creating, sending, and receiving electronic invoices in structured data formats (such as XML).
Legal Basis
The Growth Opportunities Act (WtChancenG) forms the legal basis for the introduction and implementation of e-invoicing in Germany. It aims to enhance growth opportunities, promote investments, support innovation, and improve tax simplification and fairness. This law is part of the efforts to standardize electronic invoice exchange and further advance digitization in the business sector.
More information can be found here (in German):
What Are E-Invoices?
An electronic invoice (e-invoice) is an invoice that is issued, transmitted, and received in a predefined structured electronic data format in accordance with the European standard series EN 16931, enabling electronic processing.
Important: Invoices sent by email in PDF format do not qualify as e-invoices under the EU directive. PDF invoices and paper invoices will be considered "other invoices" as of 2025.
Why E-Invoicing?
Electronic invoices reduce manual effort and the likelihood of errors since data can be exchanged directly in digital form. Furthermore, e-invoicing improves the transparency and traceability of the invoicing process and ensures higher compliance, especially with regard to tax requirements. Digital automation reduces costs and accelerates the entire invoicing process.
Variants of E-Invoicing
ZUGFeRD (PDF/A-3)
The PDF/A-3 format is a specialized variant of the PDF standard used for long-term archiving of documents. In the context of e-invoices, PDF/A-3 is particularly relevant because it allows the embedding of structured invoice data (XML). This ensures that both the visual presentation and the machine-readable data are contained within a single document, which is necessary for digitalization and legally secure invoice exchange.
X-Rechnung (XML)
X-Rechnung is the standard for electronic invoice exchange with public authorities in Germany. The XML format used is primarily machine-readable. The standard includes various technical components such as the specification itself, tools for validating national business rules (e.g., Schematron and XSL files), code list representation in Genericode 1.0, an open-source reference implementation for XML compliance checks, test messages, and invoice visualization support.
Typically, an internal system solution is used for visualizing X-Rechnung datasets, allowing for further processing of the invoice data. Several systems and tools provide components for correct display and processing of X-Rechnungen.
E-Invoice (Template)
The e-invoice template is a prebuilt database containing all necessary features for generating e-invoices and can be accessed from the available database templates.
Important:
- The e-invoice template meets the minimum requirements for e-invoice creation.
- Due to the numerous customization options available during invoice creation, it is not a plug-and-play solution but instead facilitates adaptation and implementation to meet specific operational needs by providing the required scripts and functions.
- It is the responsibility of developers to review and implement invoicing requirements for their own use cases.
Template Documentation: Incoming Invoices
Structure
The "Incoming Invoices" section includes an overview of imported invoices (page). The integrated view refers to individual records of the hidden table “IncomingInvoices_List”.
In addition to the form view, a table view is also available.
The form view of individual invoice records contains the upload field for importing invoice documents as well as a form layout for displaying the most important invoice data. There is also a separate tab for manually entering other invoices according to the Growth Opportunities Act, another tab showing all data contained in the imported invoice in HTML format, and a tab with the validation results, which are generated automatically.
In Admin mode, an additional “Admin” tab can be accessed. This includes raw data, secondary data, and controls for the main view.
Additional information ("Zusätzliche Angaben"/Invoice Note) is stored as JSON in the “includedNotes” text field under the “Admin” tab when imported. It is displayed in the form view through an HTML view field ("Zusätzliche Angaben" - Additional Information). This avoids the need for a separate subtable for additional information and keeps the display compact.
Functions / Scripts
Importing Invoices, Field Mapping, HTML Detail View, and Validation
Location: IncomingInvoices_List (Admin required) > Image field "Upload via Drag & Drop..." > Trigger on Change (More Options)
When importing e-invoices, up to four different endpoints of the Ninox-internal Mustang server functionality are accessed using sendCommand().
The following endpoints are used for processing incoming invoices:
- "parse" – to read the invoice information
- "extract" – to extract structured data (XML) from a ZUGFeRD invoice
- "xmltohtml" – to create the HTML detail view
- "validate" – for technical validation of the e-invoice
In the first part of the code, the paths required for this process are defined, which are then used in the respective sendCommand functions.
The first sendCommand function ("parse") reads the data of the e-invoice uploaded to the image field and returns it as a JSON object, which is stored in the variable resultBody for subsequent steps.
In the next section, the data is mapped to the fields defined in the template, meaning the corresponding fields are filled with the appropriate data (see technical documentation).
The first mapping also saves the complete JSON in the field "mustang json" (Location: Tab “Admin”).
Once the mapping has been completed, validation takes place via sendCommand() and the response received is then saved and processed. The XML of the response is stored in the “Validation_Response” text field in the “Admin” tab, the label (valid/invalid) is read separately and the resulting validation status is stored in the “Validation_Label” field in the same place.
The errors and notes contained in the XML of the validation response are prepared as an HTML view in the “Validation_View” formula field in the “Validation” tab.
The subsequent section of the script sends the invoice data directly (XRechnung) or via the detour of extracting (extract) the XML data (ZUGFeRD) via sendCommand to the endpoint xmltohtml for the creation of the detailed HTML view. The view received as a response can be used unchanged, but is visually adapted in this implementation by extracting and replacing the CSS stylesheet in the variables “extract” and “mystyledhmtl”.
The last script section regulates the automatic assignment of known debtors via vatID (sales tax identification number) or taxID (tax number).
Manual Entry – Data Transfer
Location: IncomingInvoices_List > Tab 'Manuelle Erfassung' (Manual Entry) > Button 'Rechnung erfassen' (Capture Invoice)
Transfers the manually entered data into a regularly captured invoice entry.
Selection Values / Codes
Location: Admin (Admin access required)
The EN16931 standard requires the specification of certain invoice information, such as currencies or units of measure, in the form of codes. In the relevant sections of the template, dynamic selection fields refer to custom code lists created in the "Admin" section and stored in formula fields. Corresponding entries in incoming invoices, such as "H87" for the unit "piece", can thus be displayed in a readable format in Ninox.
Since only a small portion of the available codes are typically needed, it is advisable to tailor the lists to the specific requirements at hand. Using the editor in the "Admin" section, the default lists can easily be shortened, expanded, or supplemented with translations or custom notes. Separate lists can be created for incoming and outgoing invoices.
Template Documentation: Outgoing Invoices
Structure
The "Outgoing Invoices" section consists of a list of already generated invoices and drafts (page), with their original records stored in the hidden table 'Ausgangsrechnungen_Liste' (OutgoingInvoices List)
A record consists of a form for entering invoice-relevant information and a separate tab for displaying the detailed validation results.
In Admin mode, an additional tab "Admin" can be accessed. This includes raw data, secondary data, and control elements for the main view.
Scripts
Invoice Creation (XML and PDF) + Invoice Numbering + Validation
Location: OutgoingInvoices_List (Admin required) > Button “Create Invoice” > On Click
The first section of this script checks for the activation of the small business regulation and also verifies necessary details for generating a valid invoice.
This section also generates the invoice number based on the configuration stored under “Settings”.
In the next part, two JSON objects are created to carry the data required for generating the invoice XML and the corresponding PDF/A-3 document. The variable datacarbone holds the data for creating the PDF document. This JSON data is passed to the dynamic print layouts stored in the print section. The resulting PDF is then sent together with the invoice data stored in the datajson variable via sendCommand to the combine endpoint, which returns the finalized ZUGFeRD document.
Both JSONs are stored in the “Admin” tab (Admin required) for easier review and debugging.
A switch function myTemplate is used to select the appropriate print layout.
After creation, the invoice is sent again via sendCommand to the Mustang server for validation. The validation result is stored in the Validierung_Response field in the “Admin” tab, and any included errors or notes are displayed as an HTML view in a form field in the “Validation” tab.
Generating Required Notes (includedNotes) Based on Invoice Type
Location: OutgoingInvoices_List (Admin required) > Dynamic selection field “Invoice Type” > Trigger on Change
In addition to the standard legal company information, certain invoice types require additional notes.
For example, when issuing correction invoices, a reference to the original invoice is generated.
Selection Values / Codes
Location: Admin (Admin required)
The EN16931 standard requires the specification of certain invoice information such as currencies or units of measure in the form of codes. At the relevant points in the template, dynamic selection fields reference individually created code lists located in the “Admin” section, stored in formula fields.
Since in most cases only a small subset of codes is actually needed, it is advisable to adapt the lists to specific requirements. Through the editor in the “Admin” section, the default lists can be easily shortened, expanded, or enhanced with translations or individual notes.
Template Documentation: Admin Area
CODE Editor, CODES, and Libraries
The European e-invoice standard EN16931, as well as the ZUGFeRD and XRechnung formats, require specifying invoice details like currencies or units of measure using codes. Standards such as ISO, UNTDID, or others are referenced depending on the context of use, and these, like the formats themselves, are subject to continuous change.
The code lists often contain far more entries than are needed in a given application, and the surplus of unused codes can hinder practical use of the e-invoice implementation.
Introduced in version 1.1.0, the CODE Editor allows users to create custom code lists based on the original ones. It also significantly improves user-friendliness by enabling the translation and addition of display values (captions).
All codes are stored in a subtable ("Typecodes") along with their display value and relation to the corresponding category/code list.
In the “CODES” tab, these entries are used to dynamically generate the code lists used in template selection fields or mappings (in JSON format).
These usually consist of an id attribute for the required code and a caption with the correct label, translation, and/or additional explanations. The currency code list also includes currency symbols (symbol). Both id and caption are natively supported by Ninox dynamic fields, allowing the codes to be extracted from or assigned to selection fields without additional scripts.
The “Libraries + Additional Resources” tab includes the original lists that the editor is based on.
CSS
The “CSS” tab contains stylesheets from various areas of the template to keep the scripts more manageable.
Currently, the stylesheets included cover:
- Detailed view of incoming e-invoices
- Dashboard widgets with current KPIs
- Display of invoice totals for incoming and outgoing invoices
Changelog
Overview of new features, changes, and bug fixes introduced with each version of the template.
Technical Documentation
This section describes the implementation and use of e-invoice functions in Ninox for creating and receiving e-invoices.
Technical Documentation: Incoming Invoices
This section documents the steps required to process an incoming invoice. To verify an incoming invoice, it must be made human-readable so it can be either rejected or accepted, booked, and paid.
The following steps are required or at least recommended:
- Make the e-invoice file available in Ninox
- Validate the e-invoice
- Read the e-invoice
- Store the e-invoice data in Ninox
- Visualize the e-invoice data
1. Make E-Invoice File Available in Ninox
E-invoices are usually received by email. For processing in Ninox, the file must be transferred to Ninox, which can be done, for example, using the Ninox Mailhook.
Alternatively, the file can be attached to a record or uploaded to an image-type field. In the e-invoice template, the upload takes place via an image-type field, which triggers a script to initiate the subsequent processing steps.
2. Validate E-Invoice
Not all received invoice files will be valid e-invoices:
Valid exceptions from the e-invoice obligation
- Small-value invoices up to 250 euros
- VAT-exempt transactions
- Foreign suppliers
- Suppliers with an alternative invoice format agreed upon during the transition period
Invalid e-invoice files
- Unknown file format
- PDF file contains no XML data
- Invoice does not meet formal requirements
The Mustang Server offers a dedicated API function for technically validating an e-invoice.
Mustang Server Function: validate
The Mustang server function validate is documented as follows:
Checks a PDF or XML file for syntactical and mathematical correctness. Input file must be a PDF/A file (Factur-X, Order-X, ZUGFeRD) or a XML file (Factur-X, Order-X, ZUGFeRD, XRechnung(CII)), output will be a XML report.
This means that this function expects an e-invoice file in one of the formats mentioned as input and delivers a result report in XML format as output.
Answers and possible error types are documented in the Mustang Server open source project:
Calling the Mustang Server Function validate via Ninox Script
From Ninox, the Mustang Server functions can be called using the sendCommand() function:
sendCommand(connectionName, command, options, files)For mustang/validate, the call might look like this:
let connectionName := "Mustang";
let command := "POST /validate";
let requestBody := {
"formData": {
"file": "_files[0]"
}
};
sendCommand(connectionName, command, requestBody, files(this));The parameters connectionName, command, and requestBody must match the structure above for the function to work.
This example assumes that the file to be validated is the first attachment of the current record (this).
- The Ninox function files
()returns the attached files as an array. - The
sendCommandfunction uses this array as its optional fourth parameter. - The string
"_files[0]"refers to the first file in the array by convention.
If you'd prefer to explicitly select a file, use:
let file := file(this, Filename);
sendCommand(connectionName, command, requestBody, [file]);Filename is the name of the desired file attachment.
In this case, Mustang, and therefore also the sendCommand function, returns an XML text with the check result.
3. Read E-Envoice
E-Invoices have different formats, both in terms of the file type (e.g. ZUGFeRD-PDF and XRechnung-XML) and in terms of the data structure (e.g. CII, EBL) and the content specifications (e.g. EN16931 profile).
With the help of the Mustang Server, it is possible to read the invoice data in standardized JSON format in a uniform structure.
Mustang Server Function: parse
The Mustang server function parse is documented as follows:
Reads a Factur-X file into an invoice object. Requires a PDF or CII or UBL XML file.
This means that this function expects an e-invoice file in one of the formats mentioned as input and delivers the invoice data in JSON format as output.
Further information on the structure of the invoice data used by the Mustang Server can be found in the Mapping section.
Calling the Mustang Server function parse via Ninox Script
Calling the /mustang/parse function from Ninox is similar to calling the /mustang/validate function described above, except for the verb in the function name.
The call then looks like this, for example:
let connectionName := "Mustang";
let command := "POST /parse";
let requestBody := {
"formData": {
"file": "_files[0]"
}
};
sendCommand(connectionName, command, requestBody, files(this));The same parameters and options apply as described above for validate.
The statements on unchangeable and changeable parameters correspond to those mentioned for the mustang/validate function.
Mustang, and therefore also the sendCommand function, returns a JSON object if successful
4. Storing E-Invoice Data in Ninox
When storing e-invoice data, distinguish between:
- Archiving the original e-invoice data in a GoBD-compliant way
- Saving invoice data for further business use, such as:
- Visualization
- Invoice verification
- Project billing
- Payment processing
- Cash flow management
- Pre-accounting
- Management reporting
The first requirement follows from the legal requirements. A document management system (DMS) or another compliant digital archiving system is required to fulfill this requirement. In the SME sector, the services offered by DATEV e.V. are often used for this purpose, such as DATEV Unternehmen Online. For online export to DATEV, Ninox has been offering an integration solution for Ninox Private Cloud customers since January 2024. Further information is available at partner@ninox.com
The second requirement comes from the business context. Ninox offers various field types for storing data. For recommendations, see the Mapping section of the documentation.
5. Visualizing E-Invoice Data
Regardless of the e-invoice format, the machine-readable XML data must be visualized for human users.
- ZUGFeRD invoices include a PDF representation, but the legally binding content is in the XML.
- For pure XML invoices, interpreting the content manually would be complex.
If the extracted invoice data is saved in Ninox tables, it can be visualized there. However, since many fields are rarely used, typically only essential data is stored this way.
To offer users a complete view, Mustang Server can generate an HTML version of the XML data.
Mustang Server Function: extract
This function extracts XML from a ZUGFeRD or Factur-X PDF or XML file.
Input: PDF must be ZUGFeRD or Factur-X; XML must be one of: xr, zf, fx, or ox.
Calling Mustang Server Function extract via Ninox Script
The call to the /mustang/extract function from Ninox is similar to /mustang/validate, differing only in the function name.
let connectionName := "Mustang";
let command := "POST /extract";
let requestBody := {
"formData": {
"file": "_files[0]"
}
};
sendCommand(connectionName, command, requestBody, files(this));The rules for fixed and changeable parameters are the same as for mustang/validate. If successful, the function returns the invoice data in XML format.
Mustang Server Function: xmltohtml
This function is documented as follows:
Visualisation from XML to HTML.
This function expects an e-invoice file in XML format as input and returns the invoice data in HTML format.
Output Language Options via URL Parameter:
- DE: German
- EN: English
- FR: French
Calling xmltohtml via Ninox Script
let connectionName := "Mustang";
let command := "POST /xmltohtml?language=DE";
let requestBody := {
"formData": {
"file": "_files[0]"
}
};
sendCommand(connectionName, command, requestBody, files(this));As with other Mustang functions, the returned output is a block of HTML-formatted text.
Displaying HTML Data in Ninox
You can either:
- Save the HTML text as a file attachment on a record, or
- Embed it in an iframe:
let myfileurl := fileUrl(mein_datensatz, "meine_rechnung.html"); html(--- <iframe width="99%" height="99%" src='{ myfileurl }' style="margin: 0; padding: 0; border: none;" class="viewer" /> ---)Technical Documentation: Outgoing Invoices
This section outlines the steps for creating an outgoing invoice.
Two Types of E-Invoices:
- ZUGFeRD
- XRechnung
Required Steps:
- Enter e-invoice data
- Prepare e-invoice data for PDF output (ZUGFeRD only)
- Create document in PDF/A-3 format (ZUGFeRD only)
- Prepare data for Mustang Server
- Create the e-invoice file
- ZUGFeRD
- XRechnung
- Visualize the e-invoice file
- Send the e-invoice file
1. Enter E-Invoice Data
To create an e-invoice, you must first enter the relevant data. Required fields depend on legal regulations and the chosen profile (e.g., EN16931). See the Mapping section for more.
2. Prepare E-Invoice Data for PDF Output (ZUGFeRD Only)
A visual PDF/A-3 version of the invoice is needed for ZUGFeRD. You can generate this using the Carbone print function in Ninox (dynamic print layout).
To automate this, use the Ninox script printAndSaveRecord(). You’ll need a template (e.g., MS Word) and data in JSON format.
Further information on the necessary preparation of the print data can be found in the documentation of the Ninox script function printAndSaveRecord()
3. Create Document in PDF/A-3 Format (ZUGFeRD Only)
The base of a ZUGFeRD invoice is a PDF/A-3 file. It can be created using:
printAndSaveRecord(this, "Invoices", {
Name: "John Doe",
Age: 42,
_options: { pdfVersion: 3 }
});You can also specify the PDF/A-3 format in the settings of the Carbone layout used for invoice creation.
The created document should be stored as an attachment to a record so it can be further processed as an e-invoice.
4. Preparing E-Invoice Data for Mustang Server
The Mustang Server expects invoice data in JSON object format.
See the Mapping section for key fields and best practices.
5. Creating an E-Invoice
5a. Creating E-Invoice in ZUGFeRD Format
To create an invoice in ZUGFeRD format, the visual PDF/A-3 must be enriched with invoice data in XML format.
Supported XML formats:
UBL (Universal Business Language): This is a widely used standard for electronic documents, especially invoices. UBL was developed by the OASIS standards consortium and aims to facilitate the exchange of business documents between organizations regardless of their technical infrastructure. UBL offers a library of XML-based schemas and is therefore highly adaptable to different industries and regions.
CII (Cross-Industry Invoice): Developed by UN/CEFACT, CII is another standardized format for electronic invoices that is designed to be highly flexible. It is designed to support a wide range of business scenarios and can be used across all industries. CII is also based on XML and is often used for European e-invoicing systems, particularly as it complies with EU regulations.
The Mustang Server provides the combine function for enriching a document in PDF/A-3 format with invoice data in one of the XML formats mentioned.
Mustang Server Function: combine
Combine PDF/A file and JSON invoice object. Output PDF will be a ZUGFeRD/Factur-X PDF/A-3 file called invoice.pdf.
Requires a input PDF/A-1 or A-3 file, a format (ZUGFeRD = zf, Factur-X = fx or Order-X = ox), a version (usually 2 for ZUGFeRD and 1 for Factur-X) and a profile ("MINIMUM","BASICWL","BASIC","EN16931","EXTENDED" or "XRECHNUNG" for Factur-X, for ZUGFeRD 1 "BASIC","COMFORT" or "EXTENDED"). Order-X currently accepts only PDF/A-1 as input PDF.
This means that this function expects a PDF document in PDF/A format and invoice data in the form of a Mustang JSON object as input and delivers the e-invoice file in the specified format as output.
The default values (format: ZUGFeRD, version: 2, profile: EN16931) can be overwritten via parameters.
Calling Mustang Server Function combine via Ninox Script
Calling the /mustang/combine function from Ninox is similar to calling the /mustang/validate function described above, except for the verb in the function name and the json attribute in the formData object of the requestBody parameter.
In addition, the above-mentioned parameters format, version and profile can be transferred.
The call then looks as follows, for example:
let connectionName := “Mustang”; let command := “POST /combine”; let requestBody := { "formData": { "file": "_files[0]", "json": { "number": "0001", "currency": "1", "issueDate": 1724803200000, "dueDate": 1726099200000, "deliveryDate": 1724803200000, "sender": { "name": "Lieferant GmbH", "zip": "80333", "street": "Lieferantenstraße 20", "location": "München", "country": "DE", "taxID": "201/113/40209", "vatID": "DE123456789", "globalID": "4000001123452", "globalIDScheme": "0088" }, "recipient": { "name": "Kunden AG Mitte", "zip": "69876", "street": "Kundenstraße 15", "location": "Frankfurt", "country": "DE" }, "zfitems": [ { "price": 5.5, "quantity": 1, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 4.9, "quantity": 1, "product": { "unit": "H87", "name": "Haustürlieferung", "description": "789", "vatpercent": "1", "taxCategoryCode": "3" } } ] } } }; let base64URL := sendCommand(connectionName, command, requestBody, files(this));
The statements on unchangeable and changeable parameters correspond to those mentioned for the mustang/validate function.
If successful, Mustang and therefore also the sendCommand function returns a ZUGFeRD PDF file in base64URL format. This can then be saved as follows:
importFile(this, text(base64URL), "e-invoice.pdf");
5b. Create E-Invoice in XRechnung format
With the invoice2XML function, Mustang Server offers the option of creating invoice data in an e-invoice file in a pure XML format.
Mustang Server Function: invoice2XML
The Mustang Server function invoice2XML is documented as follows:
Invoice class to XML. Input must be JSON.
This means that this function expects invoice data in the form of a Mustang JSON object as input and delivers the e-invoice file in the specified format as output.
Further information on the structure of the invoice data used by the Mustang server can be found in the Mapping section.
Calling invoice2XML via Ninox Script
Calling the /mustang/invoice2XML function from Ninox is similar to calling the /mustang/combine function described above, except for the verb in the function name and the slightly different requestBody parameter.
In addition, the above-mentioned parameters format, version and profile can be passed.
The call then looks like this, for example:
let connectionName := “Mustang”; let command := “POST /invoice2XML”; let requestBody := { "body": { "number": "471102", "currency": "1", "issueDate": 1721260800000, "dueDate": 1722384000000, "deliveryDate": 1721952000000, "sender": { "name": "Lieferant GmbH", "zip": "80333", "street": "Lieferantenstraße 20", "location": "München", "country": "DE", "taxID": "201/113/40209", "vatID": "DE123456789", "globalID": "4000001123452", "globalIDScheme": "0088" }, "recipient": { "name": "Kunden AG Mitte", "zip": "69876", "street": "Kundenstraße 15", "location": "Frankfurt", "country": "DE" }, "zfitems": [ { "price": 9.9, "quantity": 20, "product": { "unit": "H87", "name": "Trennblätter A4", "description": "456", "vatpercent": "1", "taxCategoryCode": "3" } }, { "price": 5.5, "quantity": 50, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 5.5, "quantity": 24, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 9.9, "quantity": 3, "product": { "unit": "H87", "name": "Trennblätter A4", "description": "456", "vatpercent": "1", "taxCategoryCode": "3" } } ] } }; let base64URL := sendCommand(connectionName, command, requestBody);
The statements on unchangeable and changeable parameters correspond to those mentioned for the mustang/validate function.
If successful, Mustang and therefore also the sendCommand function returns the invoice data as XML (CII). This can then be saved as follows:
let resultxml := item(item(sendCommandResponse, "result"), "body");
createTextFile(this, text(resultxml), "e-invoice.xml");6. Visualizing the E-Invoice File
Self-created XML invoices can be visualized like incoming ones using Mustang’s xmltohtml function.
7. Sending the E-Invoice File
The completed e-invoice must ultimately be delivered to the recipient, typically by email. Ninox provides the sendEmail script function for this purpose.
Resources & Tools
Below is an overview of the information needed for implementation, including mappings, standards, API endpoints, and additional tools.
Mapping
BT / Mustang Invoice Class Mapping
(BT = Business Terms)
For detailed information on requirements and mapping of business terms in ZUGFeRD and XRechnung, see the respective sections, which contain links to current specifications, sample files, validation tools, and forums.
The interface between the different standards and Ninox is the Mustang Invoice Class JSON Schema. A detailed mapping of BTs is available in the related documentation. More details and tools are found under the Mustang Server section.
ZUGFeRD
ZUGFeRD Standard Documentation
Forum elektronische Rechnung Deutschland (FeRD):
- Information package on the current ZUGFeRD standard with technical appendix, code lists, and sample files for download
- Context on the introduction of e-invoicing in Germany, applicable standards, and current developments in this field
The technical appendices of the individual profiles mapped in ZUGFeRD contained in the download package for the currently valid specification, in conjunction with the respective sample invoice files, form the basis for generating valid e-invoices and images of the corresponding BTs.
XRechnung
XRechnung Documentation
KoSiT Information Portal for XRechnung:
XRechnung - XStandards Procurement
Resources:
- Current specification of the XRechnung standard including technical appendix and downloadable sample files
- Context on the introduction of XRechnung in Germany, standards, and developments in this area
The current specification’s documentation, syntax rules, validation tool, and sample files serve as the foundation for successful implementation in custom applications.
Mustang Server
Mustang Server - Resources:
- Mustang Server Manual
- Mustang API Test Environment
- Mustang API Documentation
Link: Mustang API Portal
Mustang Server API Test Environment
Link to Mustang Server Test Environment
The Mustang Server API test environment is a valuable tool for implementing e-invoice functionalities in Ninox.
In the “TryOut” section, you can test Ninox-generated Invoice Class JSONs, perform validations, and combine or split invoice components (PDF/XML) without going through the full process in the main application.
The Documentation section provides a comprehensive overview of the Mustang JSON schema.
Mustang Server API Documentation
Link to Mustang Server Documentation
The Mustang Server API documentation under the menu item Documents contains JSON Mustang Invoice Class sample schemas for invoices (Invoice - without calculated values such as total amount etc.), calculated invoices (Calculated Invoice - with calculated values) as well as individual areas of the schemas such as payment terms, which can be filled with the corresponding data from Ninox via mapping.
In the API test environment (under “Try Out”), the Mustang Server functions integrated in Ninox can be tested quickly as part of the development process.