¶ 1. The e-Invoicing Solution
¶ 1.1 Goal of the e-Invoicing Solution
TecCom e-Invoicing is the TecAlliance SaaS (Software as a Service) solution for electronic invoice exchange in the automotive aftermarket. It enables invoice senders and receivers to make substantial savings through the automation of business-critical B2B invoicing processes (“Order 2 Invoice Flow”).
Through conformance with the the legal requirements of different countries, process documentation (“Audit Trail”) and fulfilment of the European Signature Regulation, TecCom e-Invoicing delivers to participants a legally valid implementation of the requirements for electronic invoice delivery.
In countries with a CTC (continuous transaction control) mandate and obligatory transmission of invoice data to a platform of the finance authorities, the relevant clearing processes with the platforms of the respective finance authorities are supported.
The e-Invoicing platform can check, sign, convert and visualise invoice data and deliver it to invoice receivers as well as third parties.
An invoice portal with a graphical user interface (Web UI) and optional long-term archive, to comply with legal storage requirements, also offers fast access to the processed invoices at any time.
¶ 1.2 Features
Basically, the following scenarios for the submission to the platform, processing and delivery of electronic invoices are supported:
The following graphic provides a rough overview of the process flow for electronic invoicing when connected to the TecCom e-Invoicing Platform.
¶ 1.2.1 Data Transmission by the Invoice Sender
Depending on the selected integration depth and features of the ERP system, invoice senders can send original invoices or copies, as structured data in EDIFACT or XML format or in PDF format. They can send via a Webservice interface, middleware sending components, or an ERP component (SAP/MS Dynamics 365) in encrypted form (see also 2. Data Transmission and 4.2 Supported e Invoicing Formats).
Sender and receiver verification ensures that the receiver account numbers from the sent data match the stored business relation (see also 11. Business Relations).
The data is then processed and delivered according to the stored settings for the business relation (see also 10. Notes and Duties).
¶ 1.2.2 Mapping
Mappings can be used for the transformation from one data format to another. The use of a mapping is determined automatically. It depends on the data format transmitted by the invoice sender and the data format selected by the invoice receiver as well as the format required for any workflow, i.e. fiscal clearing and roaming (see also 4.1 Mapping/Transformation).
¶ 1.2.3 Visualization
If the invoice receiver requires a PDF visualisation and the invoice sender has not sent a PDF, the structured data is visualised in a PDF invoice copy. If required, this uses a template specially prepared and saved for the invoice sender (see also 5.1 PDF Visualisation).
¶ 1.2.4 Signature (Signing)
If the workflow or invoice receiver requires a PDF signature, a qualified electronic PDF signature is added to the PDF invoice. The PDF signature is based on a qualified certificate and prepared with a secure signature generation device in accordance with Art. 5 Par, 1 EU Signature Guidelines (see also 5.2 PDF Signature).
¶ 1.2.5 Validation
Depending on the settings for the sender organisation, receiver organisation and the selected workflow, a validation of the invoice data is performed, e.g. for certain organisations or CTC mandate countries (see also 4.5 Validation).
¶ 1.2.6 Fiscal Clearance (CTC Platforms)
Depending on the settings for the sender organisation and the country-specific requirements, the invoice data is sent to the clearing platform of the responsible finance authority before or in parallel to its being sent to the invoice receiver (see also 7. Fiscal Clearance).
¶ 1.2.7 Roaming
According to requirements, invoice data can be transmitted via incoming roaming, outgoing roaming or to other networks, providers or additional third parties (see also 2.2 Roaming).
¶ 1.2.8 Delivery to the Invoice Receiver
At the end of each transaction, the invoice data is encrypted and provided to one or more of the invoice receiver’s receiving channels in the desired format. These may include webservice interfaces, middleware receiving components, ERP functional components (SAP / MS Dynamics 365), and e-mail (see also 2.1 Transmission Paths and 4.2 Supported e Invoicing Formats).
As an option, after completion of the transaction the invoice sender can receive a log with a listing of all process steps, delivery forms and time of the invoice delivery to the invoice receiver or any involved third parties (see also 3.5 Transaction Log).
¶ 1.2.9 Invoice Portal (TecCom Portal / Bill Presentment)
Invoice and transaction data are automatically available for all participants in the online invoice portal (TecCom Portal / Bill Presentment). In the invoice portal the status of invoices can be managed and the documents downloaded (see also 9.3 Customer Portal).
¶ 1.2.10 Long-Term Archive
The storage time of document data can be extended to up to 12 years by requesting a long-term archive option (i.e. due to a legal requirement or desired storage length). See also 3.6 Long Term Archive.
If a user books the Long-Term Archive option, his invoice data is also stored for the selected term in a revision-proof form that is available for display in the invoice portal (see also 9.2 Long Term Archiving).
As an alternative, after processing invoice data can be retrieved by the invoice sender or the invoice receiver and integrated into its own long-term archive (see also 10.1.2 Archiving of the Legally Valid Original Document).
¶ 1.3 Explanation of Terms for TecCom e-Invoicing
¶ 1.3.1 Cloud Invoice and Legacy e-Invoicing (previously “TecInvoice”)
As a reaction to the growing complexity of e-invoicing due to legal requirements, the growing number of CTC mandates worldwide, customer requirements for additional sending and delivery channels and data mappings, the legacy e-invoicing solution (previously “TecInvoice”) was redesigned as a serverless application with the working title “Cloud Invoice” at the beginning of 2023.
The goal of Cloud Invoice is the seamless integration in the processes and process logic of Order Core (TecOrder) and simultaneous expansion to meet worldwide e-invoicing requirements.
Cloud Invoice is already being successfully used productively. Nevertheless, invoice data will still be partly processed with TecInvoice until the complete inclusion of all TecInvoice features in Cloud Invoice in mid-2025. This depends on the specific requirements.
The terms “TecInvoice” and “Cloud Invoice” are useful for better internal distinction between the two systems. Customers see a single TecCom e-invoicing solution that is marketed under the name “TecCom e-Invoicing”. The platform decides automatically which system will be used at the time of data transmission.
¶ 1.3.2 Downward Compatibility of Cloud Invoice
As a rule, new customers will be connected to Cloud Invoice due to the actual process requirements, but in some cases they may be connected to legacy e-invoicing. With each new feature added to Cloud Invoice, additional customer groups will automatically be migrated from legacy e-invoicing to Cloud Invoice. This migration will not normally be noticed by the customer.
In order to make this possible, a routing component was added to the Webservice interfaces “TOM WSDL Wrapper” and “SOAP Wrapper”. Depending on the data transmitted during authentication, the router determines the system environment to use to process the incoming transaction.
This allows customers to keep their current implementation without downtime.. Only the use of new Cloud Invoice features requires a migration project involving the invoice sender.
¶ 1.3.3 System-related Compatibility
Some chapters of the functional description contain overviews of available or supported transmission paths, features or formatsee Some of the following chapters provide overviews of supported transmission channels, scenarios and formatsee A yes/no assignment in a table indicates whether a channel is compatible with the respective scenario or environment.:
- “Cloud” stands for the new serverless application “Cloud Invoice”
- “Legacy” stands for the part of the legacy e-invoicing system (previously “TecInvoice”) that is operating until migration
- “Sender” stands for the invoice sender
- “Receiver” stands for the invoice receiver
- “Workflow” stands for a closed process chain
¶ 2. Data Transmission
¶ 2.1 Transmission Paths
Numerous channels are available for data transmission (sending) by the invoice sender and delivery (receiving) to the invoice receiver.
The channels for receiving can also be used by the invoice sender for back integration into its own ERP system or invoice archive. This may be necessary e.g. for legal reasons due to a requirement for legally valid archiving of invoice documents if the invoice sender does not wish to use TecCom’s Long-Term Archive. Signed or cleared invoices, mappings for the receiver and transaction logs are among the documents that may be integrated this way.
Data exchange to and from the e-Invoicing platform by all participants is exclusively encrypted with TLS (https).
| Channel | Send | Receive | Legacy* | Cloud |
|---|---|---|---|---|
| Middleware: Connect5 | Yes | Yes | Yes | Yes |
| MFT: SFTP, OFTP2, AS2 | Yes | Yes | No | Yes |
| MFT: Dropbox | No | Yes | Yes* | Yes |
| Webservice: TOM WSDL Wrapper * | Yes | No | Yes* | Yes* |
| Webservice: SOAP Wrapper * | No | Yes | Yes* | Yes* |
| Webservice: Cloud Invoice REST API | Yes | Yes | No | Yes |
| Module: SAP | Yes | Yes | Yes* | Yes |
| Module: D365FO | Yes | Yes | Yes* | Yes |
| SMTP: E-Mail Delivery | No | Yes | Yes | Yes |
| Web UI: TecCom Portal / Bill Presentment | No | Yes | Yes | Yes |
* Only legacy e-Invoice documents can be delivered using this channel (see 1.3.1 Cloud Invoice and Legacy e Invoicing)
¶ 2.1.1 Middleware Components
Middleware components enable a highly automated connection with low implementation cost. In the past, additional components (Dispatcher, PullClient, TomConnect) were offered but they have all since been replaced by Connect5.
¶ Connect5
Connect5 is a software component for the transmission of electronic documents and invoices. It can be used by invoice senders and invoice receivers to send and receive messages. Connect5 runs under the Windows operating system; it must be installed on the customer’s computer or VM (virtual machine). The message transmission and receipt is automatically executed by Connect5 in configurable intervalsee The necessary external ports for sending and receiving must be opened in the firewall.
Invoice documents that are planned to be sent are put in the file system or network path of the installation environment. The same applies to invoice documents to be received. The customer is responsible for copying the messages to be sent to the working directory of Connect5. He is also responsible for the further integration of messages received by Connect5 in the ERP system of the connected participant.
The user must ensure that the system requirements for implementation and operation are fulfilled according to the documentation that is provided during an implementation project:
- Enough available memory to receive invoice documents
- Permanent connection of the server with the Internet
- Opening of the necessary protocols and ports in the firewall
- Permanent operational readiness of the components
The customer himself performs the installation of Connect5 on the customer system (Windows) or with help from TecAlliance in a customer project. The configuration of Connect5 is performed via the TecCom Portal.
¶ 2.1.2 Managed File Transfer (MFT)
¶ AS/4, AS/2, OFTP2, SFTP (only Cloud Invoice)
With the protocols AS/4, AS/2, OFTP2, SFTP messages can be either sent or received. This method of data transmission is normally used for roaming or by EDIfact users.
The data transmission protocol is set up in cooperation with the sender or receiver. It must be confirmed on both ends by a transmission test. The sender or receiver must provide TecAlliance with the necessary parameters to configure the channel to set up the connection. TecCom books the connection costs and bills the customer accordingly. The customer bears his own costs.
¶ Dropbox
Dropbox can be used for direct data transmission to all supported systems. The customer is responsible for his own use license. Dropbox is only available to receive messages, not to send them.
¶ 2.1.3 Webservice
Connection to a Webservice interface provides deeper integration in the ERP system and the greatest level of automation. With a Webservice connection, features can be automated or linked to an ERP system that would otherwise require manual action, e.g. invoice status updates.
¶ TOM WSDL Wrapper
The TOM (TecOpenMessaging Service) WSDL Wrapper is common Webservice interface that accepts message for Cloud Invoice or legacy e-Invoicing at the same time. TOM has an integrated routing component to automatically route messages correctly to either Cloud Invoice or legacy e-Invoicing.
The customer must follow the documentation provided during the project to implement the Webservice.
In the medium term, REST API will replace the TOM WSDL wrapper, even if this will still be available for reasons of downward compatibility. An overview of the EoL (End of Life) Roadmap is available in the TecCom Wiki (see 13.4 End of Life Roadmap).
¶ SOAP Wrapper
A SOAP client with a connection to TOM (TecOpenMessaging Service) WSDL can receive messages from Cloud Invoice and legacy e-Invoicing. TOM has an integrated routing component to automatically pick up messages simultaneously from either Cloud Invoice or legacy e-Invoicing.
The customer must follow the documentation provided during the project to implement the Webservice, in particular the sending of the DDN (Document Delivery Notification) to mark messages as received.
In the medium term, REST API will replace the SOAP wrapper, even if this will still be available for reasons of downward compatibility. An overview of the EoL (End of Life) Roadmap is available in the TecCom Wiki (see 13.4 End of Life Roadmap).
¶ REST API (only Cloud Invoice)
It is recommended to invoice receivers that exclusively send and receive with Cloud Invoice to use the Cloud Invoice REST API. New exclusive Cloud Invoice functions, e.g. transmission of an invoice status like “Accepted/Rejected”, can only be used with REST API. In the medium term REST API will replace the SOAP wrapper.
¶ 2.1.4 ERP Component
¶ SAP Module
The SAP module can be used to send as well as receive messages.
The responsible function module is part of the Comfort Supply package for sending the messages, and Comfort Order package for receiving messages. The automatic further processing of the invoice documents in SAP is possible with an additional module. A project is required for the integration of SAP modules.
¶ MS Dynamics 365
The Dynamics module can be used for sending and receiving messages.
The D365 module is currently only available to invoice senders.
A project is required for integration.
¶ 2.1.5 SMTP: Email Delivery
Email can only be used to receive messages, not to submit them.
Sending by e-mail is only possible if the invoice receiver’s email address is known.
In many countries the approval of the invoice receiver may also be required.
Emails from the e-Invoicing platform are sent from noreply@invoice.tecalliance.net. Invoice senders must always also add a Reply-To email address so that the email is sent in the name of the actual invoice sender and appears in the mailbox of the invoice receiver under the name of the invoice sender. The invoice sender must ensure that his email address and the noreply-address from TecCom are allowed through any spam filters of his invoice receivers.
For secure and reliable invoice delivery, receiving via Web UI, Webservice or ERP component (SAP module) is always preferable. This is because transmission of invoice data by email, according to public knowledge and attack vectors of the business partners, provides a target for scam and phishing attacks.
The invoice sender can also use email receipt, e.g. to receive copies of documents sent to the invoice receiver. The transaction log (protocol of processing steps) can also be sent to the email address of the invoice sender in case of success or failure.
¶ 2.1.6 Online Customer Portal (Web UI)
All invoice and transaction data can be viewed and downloaded from the invoice portal for the entire storage period at no additional cost. The standard storage period without an additionally ordered long-term archive option is at least 12 months (see also 9.3 Customer Portal).
¶ 2.2 Roaming
Roaming includes all workflows that include the receipt from or delivery to another network, provider or other third party. The roaming workflow can be combined with other workflows as required.
| Roaming Channel | Inbound | Outbound | Legacy * | Cloud |
|---|---|---|---|---|
| CTC Platform | Yes | Yes | Yes * | Yes |
| Aktivbank | No | Yes | Yes | WIP |
| ERP Partner | Yes | Yes | Yes | Yes |
| VeR | Yes | Yes | Yes | WIP |
| OpenPeppol | Yes | Yes | No | WIP |
* Only in Italy
¶ 2.2.1 VeR Roaming
TecAlliance supports VeR Roaming according to VeR Specification 1.1. In this scenario, TecAlliance receives or sends invoice documents from/to another service provider according to VeR (Verband elektronischer Rechnungen/E-Invoice Alliance Germany). A special feature of VeR roaming is that documents, after receipt by TecAlliance from the other party, must be forwarded unchanged to the invoice receiver.
¶ 2.2.2 Network Roaming
Network roaming includes all networks for data exchange. A popular example is OpenPeppol. In this form of roaming either the invoice sender (outgoing roaming) or the invoice receiver (incoming roaming) is directly connected to the e-invoicing system of the provider. Providers act here as so-called access points (APs). The other party is determined dynamically at runtime according to the stored configurations and/or the routing addresses included in the transaction data.
¶ 2.2.3 ERP Partner
An ERP partner is an ERP provider that is directly connected to TecAlliance through a transmission channel. In this scenario, the ERP partner takes responsibility for sending or receiving invoices on behalf of his customers. An ERP partner can communicate with an invoice sender, an invoice receiver, a network or another ERP partner.
¶ 2.2.4 Fiscal Clearance
In fiscal clearing the clearance platform of the finance authority faces the taxpayer (invoice sender) as either the only or as an additional receiver.
It must be distinguished between the inbound flow (TecAlliance receives invoice data from the platform and sends them to the receiver) and the outbound flow (TecAlliance sends the invoice data on behalf of the invoice sender to the platform).
Depending on customer preference and the rules of the respective country, in the outbound flow TecAlliance can send the invoice receiver, in parallel or in addition, the original invoice or an invoice copy (see 1.2.6 Fiscal Clearance and 8. Central Settlement with Aktivbank).
¶ 2.2.5 Aktivbank
In the Aktivbank workflow, invoice data is sent exclusively (original document procedure) or additionally (copy document procedure) to the invoice regulator Aktivbank on behalf of the invoice sender and invoice receiver (see 8. Central Settlement with Aktivbank).
¶ 3. Data Processing
¶ 3.1 Scope and Purpose
¶ 3.1.1 Transmission and Processing
During the transmission of document data to the platform, control data (processing instructions) is generated and processed by the e-Invoicing platform. This data is necessary for the routing through the e-Invoicing platform. It is generated using configuration data from the sender’s sending components, parameters included in the data delivery and the structured data in the transaction.
All data (invoices, transactions, etc.) is transmitted and saved in encrypted form. A strict domain separation of productive, test and development environments is guaranteed, as is the separation of the individual participants in the e-Invoicing platform.
During message transmission, information such as receiver name, customer number and delivery option is processed. Additional required data is extracted from the structured invoice documents or transformed, i.e. to display invoices in the customer portal or generate a PDF visualisation or a data mapping.
¶ 3.1.2 Storage
All data is always encrypted and stored on the e-Invoicing platform in a way so that it cannot be accessed externally. Only authorised users (customer accounts) have access to the data. E-Invoicing processes as part of the ordered service and authorised TecAlliance employees performing support operations may also access the data.
For reasons of transparency, all invoice and transaction data is stored automatically and kept in the e-Invoicing system for 15 months; it is only deleted after that time.
The storage time of document data can be extended by booking a long-term archive option (i.e. due to legal requirements or a desired storage length) of the desired length up to 12 years.
Stored data is visible and usable for TecAlliance Support and the user (invoice receiver or invoice sender) for the entire storage time.
Data storage and processing are performed exclusively on servers and systems located within the EU.
¶ 3.1.3 Data Protection and Information Security
The processing and storage of all customer and transaction data, compliance with the valid data protection laws, and the development, operation and maintenance of the SaaS solutions for electronic invoices are monitored by an ISMS that is certified according to ISO/IEC 27001:2022 (see 13. Attachment | ISO/IEC 27001:2022).
¶ 3.2 Monitoring
¶ 3.2.1 Transaction Monitoring
All process steps, from data submission by the invoice sender until delivery to the invoice receiver and any third parties, are seamlessly monitored and fully logged by the e-Invoicing solution.
If there is a problem during the processing by the e-Invoicing system, a provider involved in the process, or a clearing platform, the transaction will be stopped or paused.
The invoice sender will be notified in this case (see 3.4 Failed Transactions).
¶ 3.2.2 Monitoring of the System Environment
All processes are continuously monitored and automatically tested. If a system error occurs, the responsible product team will be informed automatically. Customers may subscribe to the status page for the system environment in order to be informed in case of an error (see 12.2 Service Availability).
¶ 3.3 Successful Transactions
¶ 3.3.1 Successful Delivery to the System
After successful transmission to the system, the invoice sender synchronously receives a Business Transaction ID (BTID). This transaction ID enables the unique identification of the e-Invoicing transaction. If help is needed, this ID must be provided for traceability to the TecAlliance support team.
This ID also serves as the basis for the traceability of the invoice process as part of the process documentation and in Fiscal Clearance Workflows. By using the transaction ID, each process step in a transaction can be individually repeated at any time.
¶ 3.3.2 Successful Delivery
TecAlliance is not responsible for the customer’s transmission paths, such as Internet connection, server availability or monitoring the function of receiving components.
The delivery by TecAlliance is deemed to be complete as soon as the configured document is available at the agreed receiving channel.
A transaction or the delivery of the contained documents to a delivery option is considered to be successful when:
- Sending by email: Sent by the SMTP server
- Middleware components / Webservice / ERP component: Put in the download archive of the receiver on the e-Invoicing platform
- MFT: Transmission of the data to the receiving party
Delivered messages will be billed to the contract partner responsible for the transaction costs, regardless of whether the receiver has actually picked up or read the documents.
¶ 3.4 Failed Transactions
¶ 3.4.1 Failed Delivery to the Platform
If the transmission to an e-Invoicing platform is not possible, the invoice sender does not receive a transaction ID but instead an error message. Depending on the connection, this error message is sent via the Webservice Response (Webservice), by email (Connect5) or displayed in an e-Invoicing monitor (ERP component).
The error message shows why the transaction was not successful (i.e. business relation not available, authentication not successful).
If transmission fails before generation of a transaction ID, then the process cannot be traced (i.e. if there is no Internet connection) or only in part or with great effort (e.g. server log files of the e-Invoicing solution). It is therefore the responsibility of the invoice sender to ensure that the transmission of document data to the e-Invoicing platform has been successfully confirmed by the transaction ID.
Depending on the connection type, this can be achieved by monitoring email messages, file directories(Connect5), Webservice Response (Webservice) or the e-Invoicing Monitor (ERP component).
¶ 3.4.2 Documents That Cannot Be Processed
If invoice data is transmitted that cannot be processed by the invoice receiver, the invoice receiver must investigate the cause. If necessary, TecAlliance Support can help.
The invoice receiver is responsible for his own delays in further processing that are not caused by erroneous or missing data from the invoice sender.
If the cause is erroneous or missing data from the invoice sender, the invoice receiver must inform the invoice sender so that the invoice sender can correct the invoice and resend it.
TecAlliance accepts no responsibility for the content of the data made available by the invoice sender. Reclamations by the invoice receiver due to erroneous or missing data must be made to the invoice sender.
If the problem with further processing by the invoice receiver is due to an error in the e-Invoicing system (i.e. bug), TecAlliance will resolve the problem according to the TecCom Support Agreement (see 13.1 Customer Support and Availability).
If an adjustment or extension of the e-Invoicing solution is necessary or possible to resolve the customer problem, the customer (sender/receiver) can make a Change Request. The responsible product team will evaluate and possibly approve the request. If approved, it will be planned in the development schedule. Modifications may cause additional development costs that may be passed on to the customer.
¶ 3.4.3 Uncollected Documents
If documents are not picked up in time by invoice receivers with connections by Connect5, MFT, Webservice or ERP component, the invoice sender receives a suitable warning (see 3.5 Transaction Log).
¶ Legacy e-Invoicing
The invoice receiver has five days to retrieve the invoice data.
After that time the invoice sender, if the option “transaction log in case of error” is activated, is notified of the unretrieved invoice.
The status of the transaction is switched to an error but the invoice documents can still be downloaded. After the receiver downloads the invoice, the transaction status is set to “Success”.
¶ Cloud Invoice
The invoice receiver has 32 days to retrieve the invoice data.
If the option “transaction log in case of error” is activated, after four days the invoice sender receives an email notification at the saved e-mail address that the invoice has not been retrieved.
The invoice receiver also receives an email if an email delivery option has been set up.
The status of the transaction is set to “Error” and the invoice documents can no longer be downloaded if the transaction has not been downloaded within 32 days.
¶ 3.5 Transaction Log
The individual process steps are continuously and completely documented and can be made available to the invoice sender as a transaction log in the event of either success or failure.
The transaction log can be sent to the invoice sender at the email address that was entered and stored in the e-Invoicing system. It can also be sent to all transmission channels suitable for receiving (see 2.1 Transmission Paths).
The transaction log contains all relevant information on the latest status of the transaction. It also contains relevant information in case of error for failure analysis by the customer or TecAlliance Support.
Monitoring of the transaction logs, especially in the event of errors, is necessary for seamless monitoring. As part of an implementation project or when setting up new business relations, TecCom will always set up at least the delivery of the transaction log in case of error to the known email address for the invoice sender. The only exceptions are if the invoice sender has given a different email address or other delivery paths for the transaction log.
When the invoice sender receives a transaction log for a failed transaction, he must take action, either by resending or contacting TecCom Support(see 13.1 Customer Support and Availability).
¶ 3.6 Long-term Archive
The storage time of document data can be extended to up to 12 years by requesting a long-term archive option (i.e. due to a legal requirement or desired storage length).
Invoice sender long-term archive and invoice receiver long-term archive must be separately requested by the respective invoice sender and invoice receiver. They are physically separated from each other.
Documents from transactions with the long-term archive option activated will be automatically encrypted and inaccessibly stored by other processes. Through additional security measures they are protected against manipulation, deletion and loss.
Data from the long-term archive will be automatically and irretrievably deleted from the long-term archive after three months after the end of the storage duration.
Direct access to the long-term archive data is not possible. Invoice download can only be performed by an authenticated and entitled user of the customer portal. Transactions with long-term archiving will be automatically displayed in the customer portal for the complete duration of storage.
The long-term archive of the e-Invoicing solution fulfils the classification criteria of most countries:
| Classification Criterion | Fulfilled by |
|---|---|
| Authenticity |
|
| Readability |
|
| Unchangeability |
|
| Correctness and Completeness |
|
| Traceability |
|
| Verifiability |
|
| Timeliness |
|
| Availability |
|
| Authorisation |
|
¶ 4. Data Formats
¶ 4.1 Mapping/Transformation
Mappings can be used for the transformation from one data format to another. The use of a mappings is managed automatically. It depends on the data format transmitted by the invoice senders as well as the data format selected by the invoice receiver or the format needed for the workflow (fiscal clearing, roaming).
In principle, mappings can convert data from any supported format to any supported format. Exceptions may occur in individual cases, e.g. due to incompatibilities between the formats or special information not available in the respective other format. Format compatibility depends on the capabilities of the invoice sender and the requirements of the invoice receiver. A final decision on the mapping options must be reached in the specific project.
¶ 4.2 Supported e-Invoicing Formats
The following table shows which formats are available to the sender for delivery to the platform and to the receiver for receiving. It also shows which e-Invoice system environment supports the respective mapping.
| Format | Type | Sender | Receiver | Legacy | Cloud |
|---|---|---|---|---|---|
| TecCom TXML 3.0 | XML | Yes | Yes | EoL | No |
| TecCom TXML 2.5 | XML | Yes | Yes | Yes | Yes |
| TecCom TXML 5.0 | XML | Yes | Yes | No | 2025 |
| ZUGFeRD 2.0 / Factur-X | XML | Yes | Yes | No | 2025 |
| EDIWheel 3.3 | XML | Yes | Yes | No | Yes |
| UN/EDIFACT D.96A | EDIFACT | Yes | Yes | Yes | Yes |
| EANCOM GS1 | EDIFACT | No | Yes | No | Yes |
| DIN EN 16931 * | Norm | Yes | Yes | No | Yes |
* DIN EN 16931 is not a specific data format but a semantic data model published by the EU Commission. The norm lists three supported data formatsee TecAlliance has defined two additional TXML Subsets that enable complete compatibility.
All country-specific formats in CTC context (fiscal clearing) are described under 7.2 Country Formats and CIUS.
¶ 4.3 e-Invoicing Subsets
A subset is a collection of rules to limit or expand the contents of a basic format through modified business rules and field length limitations for individual elements.
For certain workflows an invoice sender must send the invoice data according to the valid rules of the subset. The subset’s requirements are given by the required workflow.
Subsets can be partially combined with each other within a format.
| Subset | Basic Format | Workflow | Legacy | Cloud |
|---|---|---|---|---|
| D.96A CF | UN/EDIFACT D.96A | Standard | Yes | Yes |
| D.96A GOLDA | UN/EDIFACT D.96A | GOLDA / France | Yes | Yes |
| TXML 2.5 AB | TecCom TXML 2.5 | Aktivbank | Yes | 2024 |
| TXML 2.5 GOLDA | TecCom TXML 2.5 | GOLDA / France | Yes | Yes |
| TXML 2.5 EN16931 | TecCom TXML 2.5 | EN 16931 | No | 2024 |
| TXML 2.5 PEPPOL | TecCom TXML 2.5 + TXML 2.5 EN16931 |
OpenPeppol | No | vsl. 2025 |
| TXML 5.0 EN16931 * | TecCom TXML 5.0 | EN 16931 | No | 2025 |
| TXML 5.0 PEPPOL | TecCom TXML 5.0 + TXML 5.0 EN16931 |
EN 16931 | No | vsl. 2025 |
| OpenPeppol BIS 3.0 | UBL 2.1 ISO/IEC 19845:2015 | OpenPeppol | No | vsl. 2025 |
* TXML 5.0 EN 16931 is not a true subset of TecCom TXML 5.0. TecCom TXML 5.0 can support all fields described by the norm. However, the invoice sender and invoice receiver are not required to fill all norm fields if they are not needed to fulfil the legal requirements of the country in which tax is paid.
All country-specific subsets in the CTC context (fiscal clearing) are described under 7.2 Country Formats and CIUS.
¶ 4.4 EN 16931
DIN EN 16931 is a semantic data model published by the European Commission with business rules for e-invoicing processes. It currently contains three approved compatible formats and rules to implement the respective syntaxes.
EN 16931 is part of the ViDA draft. It is the basis for data interoperability in most European countries with current or planned CTC mandates and additional networks like OpenPeppol.
TecCom e-Invoicing supports receiving and mapping in the three basic formats of EN 16931.
| Format | Type | Sender | Receiver | Legacy | Cloud |
|---|---|---|---|---|---|
| OASIS UBL 2.1 ISO/IEC 19845:2015 (UBL 2.1) | XML | Yes | Yes | No | WIP |
| UN/CEFACT XML 16B (CII) | XML | Yes | Yes | No | Yes |
| UN/EDIFACT D14B | EDIFACT | Yes | Yes | No | WIP |
The trend in Europe is going in the direction that providers for all European countries should support the three DIN 16931 basic formats by 2030. Based on the DIN EN 16931 data model, the individual countries then set additional rules in a so-called Core Invoice Usage Specification or CIUS for short (see also 7.2 Country Formats and CIUS).
¶ 4.5 Validation
Validation is the check of invoice data before delivery to the invoice receiver. This gives the invoice sender the chance to correct erroneous invoice data before it is sent to finance authorities, active third parties and invoice receivers.
Depending on the rule set used, validation can check structure and/or content. In structural validation, schema validation tests the transmitted data for structural construction and the presence of all required fields.
Content testing uses additional rule sets. An example is the comparison of the reported totals and tax totals with the calculated totals based on the items and tax rates included. Another test is the check of logical dependency of certain information and fields according to the valid business rules from the format and workflow.
Validation is possible but in principle optional for sender and receiver. If at least one of the two sides has activated validation, the test becomes obligatory. Transmitted documents for which validation has failed will be rejected by the e-Invoicing system with an error message and not further processed or sent to the receiver.
In addition, for certain scenarios validation is mandatory due to process requirements. These validations are coupled to the respective workflow and cannot be deactivated. A workflow’s validation rules are set by the regulatory requirements of the finance authorities in countries with CTC mandates (e.g. France) and process requirements of third parties(e.g. Aktivbank) and partner networks (e.g. OpenPeppol).
| Validation | Workflow |
|---|---|
| TXML 2.5 Standard | Optional |
| Aktivbank (Original / Kopie) | Aktivbank |
| GOLDA D.96A | GOLDA |
| GOLDA GS1 | GOLDA |
| GOLDA Ediwheel 3.3 | GOLDA |
| GOLDA TXML 2.5 | GOLDA |
| CTC Poland | CTC Poland |
| CTC Mexico | CTC Mexico |
| CTC Spain | CTC Spain |
| CTC France | CTC France |
| CTC Italy | CTC Italy |
¶ 5. PDF and Signature
¶ 5.1 PDF Visualisation
At least one structured data format (EDIFACT/XML) is required for the invoice sender to transmit invoice data to the e-Invoicing platform. For an invoice document, the invoice sender can prepare a visualisation in the form of a PDF.
If the invoice sender does not provide a PDF, the e-Invoicing platform can optionally prepare one using a standard template. On request the logo of the invoice senders can be stored for use.
PDF visualisations currently use the French, English and German languages. The language of the generated PDF depends on the country setting of the invoice receiver. If that country’s language is not available, English will be selected as the standard language.
Customised templates can be prepared for invoice senders. One can be requested through Support, Sales or the responsible project manager.
¶ 5.2 PDF Signature
The signature generated for e-Invoicing is a qualified electronic PDF signature that is based on a qualified certificate (valid at the time of generation) and generated by a secure signature generation unit according to Art. 5 Par, 1 EU Signature Guidelines. It confirms that the integrity of the invoice data, identifies the invoice sender and thus verifies the authenticity of the origin.
The software digiSeal® server from the company secrypt GmbH is used. This software generates and tests electronic signatures and time stamps digiSeal® server fulfils the requirements of the German Federal Network Agency through the Proof of Conformity for the German Signature Law (manufacturer statement).
¶ 5.2.1 Signature Cards
So-called multi-signature cards are supported. These allow the generation of multiple signatures with a single PIN entry. The signature cards used are from the trust centres D-TRUST GmbH (a subsidiary of the German Federal Printing Office) for Germany and Quo Vadis for Switzerland.
The trust centre fulfils the requirements of the German Federal Network Agency:
- Proof of Conformity for the German Signature Law (manufacturer statement)
- Control of the signature key owner over signature generation
¶ 5.2.2 Verification
To ensure the integrity and authenticity of the invoice, the validity of the signature is verified and the result of the test saved in a so-called verification report. The verification report can be sent to the invoice sender and receiver as a PDF document or saved in an archive. The verification report is generated in the language of the invoice receiver.
For verification the software digiSeal® from the company secrypt GmbH is used. The certificate belonging to the signature is checked locally with the certification path and online with the trust centre. This fulfils “verification depth 3”, which means that all certificates back to the root certificate of the German Federal Network Agency are checked.
¶ 6. Original Invoice & Copy
In principle, any document transmitted or generated in a transaction can fulfil the function of an original invoice under tax law (=invoice document that authorises an input tax deduction).
However, depending on the tax jurisdiction of the invoice sender, the workflow used, the country and the requirements of the invoice receiver— some requirements must be considered that can influence which document may or must be the original invoice.
¶ 6.1 Agreement between Sender and Receiver
¶ 6.1.1 Choice of the Original Invoice
As a rule, one of the possible documents included in a transaction must be declared to be the original invoice. This is then binding for both the sender and the receiver.
This is possible by marking the document in the invoice data, i.e. with a notation ‘Copy’ or ‘Duplicate’ on the invoice copy and a corresponding note on the original invoice. Paper invoices or PDF documents can contain a notation. Structured data has an element that can be used for this purpose.
The invoice sender and invoice receiver must agree on which of the transmitted documents is the original invoice. Depending on the workflow, it might need to be configured on the e-Invoicing platform.
Normally the invoice sender determines the document for the original invoice. However, the invoice receiver may influence this decision in consultation with the invoice sender.
¶ 6.1.2 Revision-Proof Archiving
Both the invoice sender and invoice receiver must independently ensure that the original invoice is archived in a revision-proof form for the required time and accessible and viewable by any tax auditor. Each must meet the country requirements for the company (usually the site of tax registration of the invoice sender / invoice receiver organisation).
If the invoice sender uses his own long-term archive, he must ensure that the original invoice is automatically transferred to that archive. This is particularly relevant for invoice senders that use a workflow where the original invoice is generated by the e-Invoicing platform (i.e. by a mapping, electronic signature or clearing with finance authorities).
The invoice receiver must equally ensure that the received original invoice is archived in a revision-proof form.
Both invoice sender and invoice receiver can each decide to use the long-term archive offered by TecAlliance. This way they avoid the respective requirements of integration and back-integration. The long-term archive of the invoice sender is independent of that of the invoice receiver and must be ordered separately by the respective company.
When using the TecAlliance long-term archive, it is sufficient that the company provide the access data so that the auditor can see the documents without delay in case of a tax audit.
¶ 6.2 Workflow Requirements
Many workflows have additional requirements. This is currently the case i.e. for central regulation by Aktivbank. The workflow limits which document may be used as the original invoice (see also 8. Central Settlement with Aktivbank).
¶ 6.3 Country Requirements
Which invoice documents in the e-Invoicing process can fulfil the function of the original invoice is particularly dependent on the country in which the VAT must be paid. As a rule this is the country in which the issuer of the invoice (usually supplier/invoice sender) is registered for taxes.
The regulations of individual countries for sending and saving invoices can differ in the following points:
- Which formats may or must be used in an original document.
- Whether copies may also be sent in addition to the original invoice.
- Which formats the copies may have (paper, PDF, XML, etc.).
- Whether and how long invoices must be archived in revision-proof form,
- Which of the documents in a transaction must be archived together with the original invoice.
- Whether and how the invoice must be approved by a clearing platform of the tax authority before or parallel to delivery to the invoice receiver.
¶ 6.3.1 Countries with CTC Mandates
In countries with a CTC (continuous transaction controls) mandate, there is either a single dedicated structured country format (XML Format) or a choice from several formats that may be used in that country. Examples of this are CFDI in Mexico, KSeF xml in Poland and one of three EN 16931 formats in France.
In CTC countries the invoice data must also be sent to the clearing platform of the tax authority in one of the allowed formats or, for some, explicitly in the dedicated country format.
¶ Centralised CTC Model
In countries with a centralised CTC model, the tax authority must confirm and approve the invoice data through the clearing platform before it may be transmitted to the invoice receiver. This can be done, for example, by the clearing platform signing the transmitted invoice data. This signature becomes part of the original invoice together with the structured data (i.e. CFDI with clearance by SAT in Mexico).
¶ Decentralised CTC Model
In countries with a decentralised CTC model, the transmission of the invoice data to the tax authority is also required, but approval is not required. As a rule, parallel delivery of the invoice to clearing and the receiver is possible.
¶ e-Reporting
Some countries (i.e. France) require additional e-reporting but it is separated . This is most comparable to a tax declaration but not part of the invoice documents.
¶ Lifecycle Status
Some countries have introduced a so-called lifecycle status together with the CTC mandate. With this, the status of a transaction can or must be communicated, i.e. the acceptance or rejection of an invoice by the invoice receiver.
¶ 6.3.2 Countries with an e-Invoicing Mandate
In some countries (i.e. Germany from 01.01.2025) there are (still) no CTC components but a so-called e- invoicing mandate applies. This means that, although prior or parallel sending to a clearing platform is not required or possible, invoices must be sent electronically.
In these countries paper invoices cannot be used as original invoices but, if appropriate, as invoice copies.
In these countries there may also be regulations on whether a PDF may still be used as an original invoice or whether only structured data is allowed as an original invoice.
¶ 6.3.3 Other Countries
In the remaining countries without a CTC or e-invoicing mandate, paper invoices are still allowed as original invoices. According to each country’s regulations, PDF invoices may be permitted as original invoices, if required in connection with a qualified electronic signature.
¶ 6.3.4 European Union until 2030
¶ DIN EN 16931
Most European countries have adapted the recommendations of the European commission in accordance with the drafts of ViDA and DIN EN 16931. These countries limit the choice of formats to the commonalities of DIN EN 16931 in a centralised or decentralised CTC model with special business rules. The following is valid for these countries:
- Centralised or decentralised CTC model
- Each of the three DIN EN 16931 formats (UBL 2.1, CII, D14B) is allowed as long as the business rules and rules for implementation in the respective syntax are followed.
- The CIUS (Core Invoice Usage Specification) must be adhered to. There are additional or modified rules based on DIN EN 16931, but are individual for each country.
In some EU countries there is an additional country-specific format that may be used, mostly for historical reasons (i.e. FatturaPA in Italy, FacturE in Spain).
¶ Exceptions
Not all EU countries follow the recommendations of the European commission. In these countries only the country-specific business rules and the specified country format are valid(e.g. KSeF xml in Poland).
There are still countries in the EU without a CTC mandate. Some of these countries will soon introduce an e-invoicing mandate as a first step (see 6. Original Invoice & Copy | 6.3.2 Countries with an e Invoicing Mandate).
It is to be expected that by 2030 all EU counties will implement a CTC model. Furthermore, it is realistic to assume that by 2030 the recommendations of ViDA and DIN EN 16931 will be implemented or planned in all EU counties.
¶ 6.3.5 Summary of Possible Scenarios
Depending on the country, one or more of the following requirements must be met for the creation and dispatch of tax-compliant invoices that authorise input tax reduction:
¶ Clearing:
- Invoice must be approved by the tax authority before delivery to the receiver
- Invoice must be sent to the tax authority in parallel to delivery to the receiver
- Invoice can be delivered directly to the receiver
¶ Original Invoice:
- Paper as original (allowed / not allowed )
- PDF as original (allowed / not allowed / allowed but only with QR Code and possibly UUID)
- Structured data as original (allowed / not allowed / choice of formats allowed / only the country-specific format allowed )
- Integrity and authenticity of the sender and the invoice data must be guaranteed (signature required / Process documentation (audit trail) of the invoice sender, providers and/or invoice receiver required
- Requirements for the long-term archive (storage duration, site of data storage)
¶ Invoice Copy:
- Invoice copies are allowed but possibly with restrictions on the possible formats
- Any invoice copies must be archived together with the original invoice
- The original invoice and invoice copies must be marked as such
¶ 6.4 Documents Available for Retrieval
The following documents are delivered to the platform or generated, depending on the process used, and are available to the invoice sender or invoice receiver for download or retrieval via Webservice, ERP component or Connect5.
| Invoice Documents and Transaction Data | Process Extension (multiple combinations possible) |
Prepared by | Download for Invoice Sender |
Download for Invoice Receiver |
|---|---|---|---|---|
| Transmitted original file (structured data) | Standard | Invoice Sender | Yes | Yes |
| Transmitted original file (PDF) | Invoice Sender | Yes | Yes | |
| Target Format Invoice Receiver | Mapping | TecCom | Yes | Yes |
| Target Format Invoice Receiver | Fiscal Clearing | TecCom | No | No |
| Target Format Invoice Receiver | Fiscal Clearing | CTC Platform | Yes | Yes |
| TXML 2.5 | Standard | TecCom | Yes | Yes |
| Master Format (Inhouse Canonical) | Standard | TecCom | No | No |
| PDF Visualisation (if not sent as original file) | PDF Visualisation | TecCom | Yes | Yes |
| PDF Signature (P7S, PK7, Swiss signature) | PDF Signature | TecCom | Yes | Yes |
| PDF Signature Verification Report (XML or PDF) | PDF Signature | TecCom | Yes | Yes |
| Transaction Log (XML) | Standard | TecCom | Yes | No |
| Auditlog (PDF) | Standard | TecCom | Yes | Yes |
| Processing Instructions | Standard | TecCom, Invoice Sender |
No | No |
| DDN´s (pull acknowledgments for invoice documents and transaction logs) | Standard | Invoice Sender, Invoice Receiver |
No | No |
| Requests and Responses from Service Providers and CTC Invoice Platforms (send to clear / cancellation / archiving, notification, acknowledge, error) |
Fiscal Clearing, Roaming | CTC Platform, Roaming Provider |
No | No |
¶ 6.5 Outlook
Which format/document may or must be used as an original invoice varies from country to country. There may be additional requirements from the country where the invoice receiver is located. Each company must analyse which formats are allowed or required for the countries in which it pays taxes. It also must check conditions it must meet to send invoices valid for the tax laws of the countries to which it is selling.
With TecCom e-Invoicing, TecAlliance has taken on the task of providing simple solutions to complex problems. TecAlliance’s consultants and experts can support you with the right connection to the e-Invoicing platform and advise you on implementing the formats you need.
Note: Even if advice from TecAlliance is process-related and based on experience, it does not constitute legal tax advice. The invoice sender/invoice receiver is solely responsible for the completeness and correctness of the transmitted data. If necessary, TecAlliance can provide names of consulting firms in this field or arrange consulting services.
¶ 7. Fiscal Clearance
¶ 7.1 CTC Mandate
More and more countries around the world are introducing CTC mandates. This includes the requirement to transmit invoice data to the finance authorities before or in parallel to delivery of the invoice to the actual invoice receiver.
The following list provides an overview of the processes supported by the e-Invoicing platform.
| CTC Mandate | Outbound | Inbound | Legacy | Cloud |
|---|---|---|---|---|
| Germany | Yes | Yes | No | TBD * |
| Italy | Yes | Yes | Yes / No | 2025 |
| Mexico | Yes | No | No | Yes |
| Poland | Yes | Yes | No | 2024 |
| Spain | Yes | No | No | TBD * |
| France | Yes | Yes | No | 2025 |
| Belgium | Yes | Yes | No | TBD * |
* The CTC for these countries will be planned and implemented as soon as the dates for the CTC mandates are published.
¶ 7.2 Country Formats and CIUS
For the transmission of invoice data to finance authorities, special data formats are needed to meet the current requirements of the respective countries. This can be a special format for the respective country or, in some European countries, one of the three DIN EN 16931 formats + CIUS.
A CIUS (“Core Invoice Usage Specification”) is a collection of rules to limit or expand the contents of a core format through customised business rules or field length limitations for individual elements. These are specified in the regulatory requirements of each CTC mandate country.
If for certain workflows, the required content and business rules cannot be included in a mapping, the invoice sender must send the invoice data according to the additional rules of the format/CIUS.
| Format / CIUS | Basic Format | CTC Mandate | Sender | Receiver | Legacy | Cloud |
|---|---|---|---|---|---|---|
| TXML 2.5 PL | TXML 2.5 | Poland | Yes | Yes? | No | Yes |
| KSeF xml FA_2 | n/a | Poland | Yes | Yes | No | WIP |
| TXML 2.5 MX | TXML 2.5 | Mexico | Yes | Yes | No | Yes |
| TXML 2.5 IT | TXML 2.5 | Italy | Yes | Yes | Yes | WIP |
| FatturaPA | n/a | Italy | No | Yes | Yes | WIP |
| XRechnung | UBL 2.1 (EN 16931) CII (EN 16931) |
Germany | Yes | Yes | No | WIP |
| CIUS-ES-FACe | UBL 2.1 (EN 16931) CII (EN 16931) D14B (EN 16931) |
Spain | Yes | Yes | No | WIP |
| CIUS for Chorus Pro CIUS for Factur-X Peppol BIS Billing 3.0 |
UBL 2.1 (EN 16931) CII (EN 16931) |
France | Yes | Yes | No | WIP |
| Peppol BIS Billing 3.0 | UBL 2.1 (EN 16931) CII (EN 16931) |
Belgium | Yes | Yes | No | WIP |
¶ 7.3 e-Reporting
In many CTC countries e-reporting must be sent to the tax authorities in addition to the e-invoice. The e-reporting format is generated by the e-invoicing platform through an additional mapping. The transmission of the invoice data in a format permitted by the CTC mandate is required so that the mapping of the required content is available
| Format | Voraussetzung | Legacy | Cloud |
|---|---|---|---|
| France e-Reporting xml | CTC France Format | No | WIP |
| FacturaE | CTC Spain Format | No | WIP |
¶ 7.4 Transmission to the CTC Platform
In countries with a CTC mandate, the finance authority provides a CTC platform (system for validation, signing and approval of the invoice data). The e-Invoicing platform is connected to this system either directly or through a partner.
Depending on the regulatory requirements of the respective country, further processing and delivery of the invoice data to the actual receiver takes place in parallel to or after approval by the CTC platform.
¶ 8. Central Settlement with Aktivbank
¶ 8.1 Overview
central settlement (CR) is a billing system for payments between suppliers and purchasing associations. Outstanding bills from purchasing contracts are processed at a central location.
Potential participants in the central settlement process of the Aktivbank are contractual suppliers located in the EU and affiliates located in Germany.
The services of the Aktivbank are primarily intended for:
- Associations (CARAT, SELECT, ad CARGO, ATEV, CAR, GA Group) and their
- Shareholders/members (affiliates) who receive invoices from the central settlement provider Aktivbank
The tax and legal framework conditions must be analysed in detail before connecting receivers in other countries.
In the central settlement process with the Aktivbank, the invoice sender (in the following also called “contractual supplier”) generates the invoice data for the invoice receiver (in the following also called “affiliate” ) together with the data for the invoice regulator (Aktivbank).
The invoice sender transmits the invoice data as usual through its connection to the e-Invoicing platform, which then delivers the invoice or credit to the Aktivbank.
The connection of the contractual supplier is similar to that described in 2. Data Transmission, 10. Notes and Duties and 11. Business Relations.
For the delivery of invoice documents to the Aktivbank and an affiliate, it is necessary to distinguish between the two processes described below, “original document process” and “copy document process”. The process that must be used depends on the purchasing association’s connection to Aktivbank and is clarified during the project.
¶ 8.2 Process Description
¶ 8.2.1 Original Document Process
In the original document process, TecAlliance transmits the invoice generated by the contractual supplier as structured data in TXML 2.5 Format only to the Aktivbank, but not to the invoice receiver. The delivery of the invoice to the affiliate is performed by the Aktivbank, if necessary with a visualisation or additional data mappings.
The structured data (TXML 2.5) is valid as an original invoice and is to be marked as original.
¶ Process Flow
- Encrypted transmission of the invoice data takes place from the invoice sender (contractual supplier) to the e-Invoicing platform. The structured data from the contractual supplier is transmitted as an original invoice and the accompanying PDF document with identical content is transmitted as an invoice copy .
- If the invoice sender delivers structured data in a format other than TXML 2.5 and uses a mapping service, the TXML generated by the e-Invoicing platform is valid as an original document. This must be archived by the invoice sender (by back-integration or the long-term archive option).
- The e-Invoicing platform validates certain data, e.g. a check if the contractual supplier has the right to send invoices.
- Encrypted transmission of received invoice data (TXML 2.5 and PDF documents) to the Aktivbank. The Aktivbank delivers the TXML message for processing in central settlement. Finally, it makes the TXML file and additional documents available to the affiliate.
- Optional archiving of the TXML file and accompanying documents in an electronic long-term archive system for the contractual supplier for the term of the legal storage requirement.
Note: the Aktivbank offers the long-term archive as an option to affiliates. - After successful delivery to the Aktivbank, a transaction log is sent to the invoice sender. In the transaction log it can be seen when the invoice was transmitted to the Aktivbank or if an error has occurred.
¶ 8.2.2 Copy Document Process
In the copy document process, TecAlliance itself transmits the invoice documents to the affiliate. Depending on the preference of the invoice receiver, this PDF can be the invoice copy or the original invoice (if needed with an additional electronic signature).
In parallel, the e-Invoicing-platform sends the Aktivbank a copy of the invoice data in the form of structured data (TXML 25) that is required for the central settlement.
¶ Process Flow
- Encrypted transmission of the invoice data from the invoice sender (contractual supplier) to the e-Invoicing platform. The contractual supplier transmits the structured data and the PDF document with identical content.
- If the invoice sender delivers structured data in a format different from TXML 2.5, the TXML 2.5 must be generated by a mapping service through the e-Invoicing platform.
- Validation of certain data on the e-Invoicing platform, e.g. a check if the contractual supplier has the right to send invoices.
- Encrypted transmission of a copy of the received invoice data (TXML 2.5) to the Aktivbank. The Aktivbank sends the TMXL message for processing to the central settlement.
- Transmission of the invoice data (PDF file, if needed electronic signature, TXML 2.5 optional) by TecAlliance to the buyer.
- Optional archiving of all invoice documents ( copy, original, if needed additional documents) in an electronic long-term archive system for the contractual supplier for the term of the legal storage requirement.
- After successful delivery to the Aktivbank, a transaction log is sent to the invoice sender. The transaction log shows when the invoice was transmitted to the Aktivbank or if an error has occurred.
¶ 8.2.3 Validation
The structured data must conform to the TXML 2.5 business rules and contain all fields required for the Aktivbank process.
The e-Invoicing platform performs a technical validation (XSD schema validation) for the presence of required entries relevant to VAT. This does not include a check of the contents.
Responsibility for the correctness and completeness of the transmitted data remains with the invoice sender.
¶ 8.2.4 Communication of e-Invoicing with Aktivbank
The e-Invoicing platform delivers the invoice data and any other documents (TXML and any associated PDF document) to Aktivbank through an https connection. The Aktivbank issues a confirmation for the received data or documents to e-Invoicing. e-Invoicing makes available the transaction log as receipt confirmation to the invoice sender through the agreed path.
¶ 8.2.5 Requirement for an Association (Purchasing Association)
¶ ad-Cargo/Carat, Select, ATEV
The structured data must be marked as original and the PDF as a copy. Aktivbank is responsible for its receiving from TecCom and the delivery of all documents to the invoice receiver.
Only possible in 8.2.1 Original Document Process.
¶ CAR, GA Group, WM SE
The TXML and PDF can be either copies or originals; they must however be marked respectively as such. The Aktivbank always receives only an invoice copy in TXML form. The invoice receiver receives the original document from the TecCom e-Invoicing platform. As an additional option, the invoice receiver may receive a copy from Aktivbank or the TecCom e-Invoicing platform.
¶ 8.3 Duties of the Invoice Sender (Contractual Supplier)
- Responsible for the correctness and completeness of the content of the invoice (including required entries for VAT).
- Checking and ensuring the matching content of the original invoice and the invoice copies in the sense of multiples with identical content.
- Marking the invoice copy as a copy or duplicate as well as a corresponding note in the original invoice that the accompanying invoice copy is not an invoice for VAT purposes and not valid for input tax deduction.
- If the service receiver and the invoice receiver are not the same, both the invoice receiver and the service receiver must be included with complete business addresses in the structured data and the PDF invoice.
- Conformance to the TecCom Business Rules and Guidelines. Mandatory performance of an “end-to-end” test with a productive invoice receiver that already processes structured data in the original document process or copy document process.
- Legally valid electronic storage including ensuring the availability and readability of the original invoice and invoice copy for the period of the legal storage time. The contractual supplier can use his own solution or separately order long-term archiving from TecAlliance.
- Contractual suppliers with SAP integration need the module TecRM. The required minimum version needs to be clarified with the SAP team during the project .
- Contractual suppliers without SAP integration need a working connection to TecCom e-Invoicing (see also 2.1 Transmission Paths).
¶ 8.4 Notes on Tax Law
¶ 8.4.1 Original Document Process
In the Aktivbank original document process, the TXML 2.5 file represents the original invoice (hereafter also referred to as the TXML original invoice). This is sent to e-Invoicing together with the accompanying PDF document (invoice copy) with identical content via the sender component or generated by a mapping. The PDF document serves exclusively as a visualisation of the TXML file for the contractual supplier. In order to avoid VAT disadvantages (see below), it is recommended that the contractual supplier mark the PDF document as copy or duplicate. He should also make a corresponding note in the structured data indicating that this is not an invoice for VAT purposes. Both files are sent to the Aktivbank unchanged and unsigned by the e-Invoicing.
For the TXML original invoice, the extended TXML 2.5 format “original document process” is used. This format is based on TecAlliance Standard TXML 2.5 and includes the business rules agreed on by suppliers and traders. The extended format also includes the necessary data for central settlement (i.e. association account number, contractual supplier account number, affiliate’s account number at the Aktivbank, Aktivbank account number at the contractual supplier). This is also described in the TecAlliance Guidelines for Invoices. If the contractual supplier cannot generate the extended TXML 2.5 Format with his existing ERP software, the corresponding mapping can be executed for the contractual supplier.
¶ 8.4.2 Copy Document Process
In the copy document process, the PDF document is the original invoice (in the following also PDF). This is sent via the sender component to e-Invoicing together with the structured data (invoice copy) with identical content. The structured data is used to control the processes within the framework of automated processing by the affiliate and the invoice regulator. To avoid VAT disadvantages (see below), it is recommended that the contractual supplier mark the structured data as a copy or duplicate. He should also make a corresponding note in the structured data to indicate that it is not an invoice for VAT purposes. The structured data is sent to the Aktivbank unchanged and unsigned by the e-Invoicing. If needed the PDF will be signed and sent to the affiliate.
For the TXML copy, the extended TXML 2.5 format “copy document process” is used. This format is based on TecAlliance Standard TXML 2.5 with the business rules agreed on by suppliers and traders. The extended format also includes the necessary data for the central settlement (i.e. account number of the association, account number of the contractual supplier, account number of the affiliate at the Aktivbank, account number of the Aktivbank at the contractual supplier). This is also described in the TecAlliance Guidelines for Invoices. If the contractual supplier cannot generate the extended TXML 2.5 format with his existing ERP software, mapping can be performed for the contractual supplier.
¶ 8.4.3 Comments on Tax and Content from the German Point of View
- The right to input tax deduction according to German VAT law § 15 UStG specifically requires that the affiliate as service receiver gain possession of the original invoice.
To this end, in the original document process with the Aktivbank, the TXML original invoice prepared by the contractual supplier or generated by a mapping service is sent in unchanged form via the e-Invoicing platform to the Aktivbank. The Aktivbank makes this available to the affiliate and ensures that the data (particularly for tax audit purposes) can be visualised and can be read for the term of the legal storage requirement. - Claiming of the input tax deduction by the affiliate also requires that the original invoice contain all legally required entries. This is stated in the German VAT law §§ 14, 14a UStG. The contractual supplier is exclusively responsible for the correct issuance of the original invoice. The affiliate has the tax-relevant duty to check the extent to which the original invoice actually allows an input tax deduction.
- For taxes, it is necessary to ensure that the structured data, any TXML file generated from it, and the PDF document are identical in content.
- The German Finance Ministry document of 2 July 2012, which was issued together with the simplification of electronic invoicing, explains that, as soon as multiple invoices are issued for one and the same service without their being marked as duplicates or copies, the supplier is (additionally) liable for the tax amount shown separately in accordance with Section 14c (1) UStG. However, according to the German tax authorities, this problem of double tax liability due to double invoice documents should not apply if only so-called multiple copies of the same invoice with identical content are sent. For this procedure there are basically two possibilities:
- Ensuring identical content (so-called multiples with identical content) between the TXML file and the PDF file.
- Clear marking of the PDF or XML file as a duplicate or copy together with a corresponding note on the original invoice that the accompanying file is a copy or duplicate that does not permit an input tax deduction. In XML, a free text element in the header can be used for this formulation.
- In the TXML file, the element <AdditionalParty> in the section <InvoiceHeader> (Qualifier “Payee”) contains, among other things, the name and address of the regulator/the Aktivbank. This data is necessary for processing by the Aktivbank. Under tax criteria the data of the regulator/the Aktivbank in the TXML file is irrelevant when observing the criteria above, in particular if the payee is clearly identified as such with a full address.
- The TecAlliance Guidelines and Business Rules for Invoices apply to the required content and structure of the structured data.
¶ 9. Invoice Portal (Web UI)
¶ 9.1 Storage of Transaction Data
All invoice and transaction data is automatically saved for 15 months for reasons of traceability. It is stored in the e-Invoicing system and only deleted afterwards.
The data can be read and downloaded for the entire storage period via the invoice portal. There are various graphic user interfaces (GUIs, Web UIs) available to different user groups for different purposes.
| Web UI | Purpose | Sender | Receiver | Legacy | Cloud |
|---|---|---|---|---|---|
| Eurolog | Customer Portal | Yes | Yes | Yes | No |
| TecCom Portal - e-Invoice Journal | Customer Portal | No | Yes | Yes | No |
| TecCom Portal - Invoice Archive | Customer Portal | Yes | Yes | No | Yes |
| TecCom Portal - Transaction Monitor | Customer Portal | Yes | Yes | No | Yes |
| Solution Portal | Support | Yes | No | Yes | No |
| TecOrder Portal | Support | Yes * | No | No | Yes |
* Only sales partners
¶ 9.2 Long-Term Archiving
The storage time of document data can be extended by any amount to up to 12 years by booking a long-term archive option. The access to long-term archive data incl. download options is automatically possible for authenticated and authorised users of the customer portal. The transactions stored in the long-term archive will be automatically displayed in the customer portal for the entire storage time.
¶ 9.3 Customer Portal (Web UI)
During the transition time until the complete migration of all customers to Cloud Invoice, invoice senders and invoice receivers can use two different GUIs as customer portals.
Customers who are still connected to legacy e-Invoicing must continue to use the Eurolog Portal. Customers who are connected to Cloud Invoice can reach the invoice archive via the TecCom Portal.
In both portals the invoice data with all associated and process-relevant documents is available. The user can display or download the documents. He can filter and search the invoice data according to various criteria. The user can only see or download the documents allowed by his user role.
In the database an invoice will be marked as read as soon as the invoice receiver has retrieved it. (Read confirmation is not possible for roaming or email delivery processes.)
¶ 9.3.1 TecCom Portal
In order to use the TecCom Portal, the customer needs a login for it. The customer themself or TecCom Support can generate the login (see 13.1 Customer Support and Availability).
At least one customer account will be assigned administration rights for the organisation. This allows hierarchical self-administration by the customer.
Changes or deletions of user master data are possible for invoice senders or invoice receivers within the scope of their user rights or through TecAlliance Support.
The portal is available in the following languages: German, English, Bulgarian, Chinese, French, Italian, Korean, Dutch, Polish, Portuguese, Romanian, Russian, Swedish, Spanish, Czech, Turkish, Hungarian, Thai, Vietnamese, Norwegian, Greek and Japanese. It uses the language selected in the user’s browser or the language selected in the TecCom Portal.
¶ TecCom Portal - Invoice Archive (only Cloud Invoice)
All Cloud Invoice transactions appear automatically in the TecCom Portal - Invoice Archive.
In the Invoice Archive, invoices can be displayed line-by-line with freely configurable columns. They can be searched and all relevant invoice documents can be downloaded.
The invoice documents are available for 15 months for viewing and downloading. As an option for an additional fee, the invoice sender or invoice receiver can order long-term archiving for up to 12 years.
The Invoice Archive is available to both invoice senders and invoice receivers.
¶ TecCom Portal - Transaction Monitor (only Cloud Invoice)
All Cloud Invoice transactions appear automatically in the TecCom Portal - Transaction Monitor. If used and available to the customer, together with orders, order confirmations, delivery notes and returns.
This view was developed primarily to monitor all business transactions and as an add-on to the TecCom Portal - Invoice Archive.
The Transaction Monitor is available to invoice senders and invoice receivers.
¶ TecCom Portal - e-Invoicing Journal (only legacy e-Invoicing)
All invoice receivers connected to legacy e-Invoicing can receive transactions in the TecCom Portal - e-Invoicing Journal. The receipt of data in this TecCom Portal excludes the receipt via Connect5 or Pull Webservice.
Electronic invoices are displayed in the e-Invoice Journal in the TecCom Portal with the most important invoice data shown in one line. The invoice documents can also be opened and downloaded.
¶ 9.3.2 Eurolog Portal (only legacy e-Invoicing)
This e-Invoicing portal is provided by the cooperation partner EURO-LOG AG.
Legacy e-Invoicing transactions can be viewed and downloaded from the Eurolog Portal for at least 90 days. As an option for an additional fee, invoices can be archived in the Eurolog Portal long-term for up to ten years.
The receiver receives an email notification for each new incoming transaction from noreply@invoice.tecalliance.net
User access to the invoice portal and the long-term archive are ordered through TecAlliance. TecAlliance forwards the appropriate user data to the cooperation partner EURO-LOG.
Access data is sent from the email address “invoice.teccom@euro-log.com”. The invoice receiver must ensure that this email address is allowed through any spam filters. The portal is available at the URL: https://portal.eurolog.com/teccom.
Changes or deletions of user master data must be requested through TecAlliance Support. TecAlliance Support will then inform EURO-LOG AG.
The portal is available in German, English, Spanish, Czech, Bulgarian and Greek. It uses the language selected in the user’s browser.
¶ 9.4 Support Portal (Web UI)
In addition to the Customer Portal, an administrative GUI is available to TecCom Support and sales partners for administrative purposes such as configuration and failure analysis. This administrative GUI can be used to configure organisations and business relations and view transaction data . Access is only granted when required, that is on customer request or in support cases.
¶ 9.4.1 Solution Portal
The Solution Portal is an administration GUI for legacy e-invoicing to configure organisations, business relations and delivery options. It is also used by TecCom Support to find errors.
¶ 9.4.2 TecOrder Portal
The TecOrder Portal is the internal TecCom administration GUI for Cloud Invoice to configure organisations, business relations and delivery options. It is also used by TecCom Support to find errors.
¶ 10. Notes and Duties
In order to guarantee the smooth transmission and processing of invoice documents, certain prerequisites must be fulfilled respectively by the invoice sender and invoice receiver before they can implement and use the e-Invoicing solution.
¶ 10.1 General Requirements and Notes
This service description and consultancy services provided by TecAlliance are no substitute for legal or tax advice. The relationships between TecAlliance and its consultants exclude a protective effect in favour of third parties. The finance administration and/or courts may have or develop different opinions on the topics discussed here.
It is the responsibility and in the interest of the customer to seek tax or business advice for the particular situation before making decisions about tax or business matters.
¶ 10.1.1 Implementation of the Transmission Path
The required prerequisites for the connection to the e-Invoicing system depend on the selected method of data transmission (Connect5, MFT, ERP component, Webservice, see 2. Data Transmission). In the course of implementation, these are agreed on with the invoice sender or invoice receiver. The customer receives the needed documentation and the available Software Development Kit (SDK) for the selected method of data transmission.
¶ 10.1.2 Archiving of the Legally Valid Original Document
Depending on the selected workflow, transmitted invoice documents can be changed or added to on the e-Invoicing platform, e.g. by generating a signature or fiscal clearing. In this case, the originally transmitted invoice document does not match the legally valid original invoice.
The invoice sender and invoice receiver must know which document in the process corresponds to the original invoice. For legal reasons and in their own interest, both parties independently from each other must take care that the original invoice is integrated into a long-term archive where it is secure against revisions. It can also be saved in a long-term archive offered by TecCom.
In the case of integration, the invoice sender or invoice receiver must ensure that sufficient memory is available on the system and that further processing (,e.g. transfer to the internal long-term archive) is always possible.
All transmission paths suitable for receiving documents are suitable for integration/back-integration (see also 2.1 Transmission Paths).
Exactly which documents must be archived depends on the selected workflow and the regulatory requirements of the country in which the the invoice sender is liable for taxes (see also 6. Original Invoice & Copy).
¶ 10.1.3 Monitoring
If a problem occurs during the processing by the e-Invoicing system, by a provider involved in the process or by the clearing platform, the transaction will be paused or stopped.
In this case, the invoice sender will be notified of the error status at the email address provided by the invoice sender and stored in the e-Invoicing system or through the implemented transmission channel (see also 3.2 Monitoring).
¶ 10.1.4 Notes on the Sending of Consolidated Invoices
According to the TecCom definition, a “transaction” is the electronic transmission of a single document via the TecCom e-Invoicing platform.
According to the TecCom definition, a “single invoice” is an invoice document with a maximum of one order reference and multiple delivery references or a maximum of one delivery reference and multiple order references. According to the TecCom definition, “consolidated invoices” are invoice documents with both multiple order references and multiple delivery references.
Transactions with consolidated invoices are basically allowed, but in certain cases they may be rejected by the invoice receiver. Sender and receiver must agree bilaterally on whether the receiver supports consolidated invoices.
In addition, consolidated invoices cannot be processed in many workflows for regulatory reasons. They are also subject to the current size limitation (see 10.2.1 Rules for Sending Invoice Documents). This can be clarified during the implementation project.
¶ 10.1.5 Guidelines and Business Rules Depending on Format and Workflow
TecAlliance defines a standard for structured data according to the selected format and workflow. This standard defines the form, structure and content of structured documents. It describes which contents and data fields must be filled and how. This is based on business rules.
This enables largely standardised and automated invoice processing by the invoice receiver and participating third parties(fiscal clearance, Aktivbank, roaming, etc.).
The valid standards were and are developed and maintained by TecAlliance in cooperation with suppliers, traders, providers and regulatory instances in consideration of largely recognised industry standards.
TecAlliance offers support for the implementation of structured data in the form of consulting on its content and generation. In addition, data mappings to and from all supported data formats are possible as long as the selected formats and required contents are compatible with each other (see 4. Data Formats).
During Implementation TecAlliance will support the customer in an advisory capacity to understand the contents and business processes required to correctly build the structured data. Test data will be used to check the correctness of the data. On request, the implementation can be tested with a pilot customer.
The organisation of the content is the responsibility of the invoice sender. Information such as e.g references, issuance of conditions, etc. must be entered correctly by the invoice sender.
The correct processing of the data content is the responsibility of the invoice receivers.
If after the conclusion of the implementation project, the invoice sender or the invoice receiver needs further advice or support on the connection, format, content or structure of the data, this must be requested additionally and paid for, depending on the type and extent.
¶ 10.1.6 Bilateral Agreements between Sender and Receiver
If the receiver and/or the sender wishes to make structural or content changes to the transmitted data format, the partners must agree on this bilaterally.
The two parties can agree on the content of the invoice data without limitation as long as they conform to the required formats and business rules for workflows or those agreed on with TecAlliance.
If bilateral agreements lead to a deviation from schema, guidelines or business rules, this can affect the validation, certification, visualisation, mapping and CTC clearing of messages. This depends on the form and extent of the deviation. The participants themselves are responsible for any bilateral agreements.
¶ 10.2 Requirements for the Invoice Sender
¶ 10.2.1 Rules for Sending Invoice Documents
The invoice sender must decide in favour of one of the data formats supported by TecCom e-Invoicing for the transmission of invoice data for each sender organisation. A different format may not be transmitted without prior agreement (see also 4. Data Formats).
As an option, the sender has the possibility to add a PDF document as a visualisation to the invoice data set or to order the generation of a PDF from the platform (see also 5. PDF and Signature).
Additional documents are not allowed in a transaction.
The sum of all transmitted data and documents in a single transaction on the e-Invoicing platform may not exceed 32 MB.
¶ 10.2.2 Monitoring
The invoice sender must ensure that the transmission of invoice data to TecAlliance was successful. Reliable transaction monitoring and error management can only be performed by the e-Invoicing system after successful transmission (see also 3.2 Monitoring).
The invoice sender must take care that the stored email addresses are available, accessible and monitored.
The invoice sender must ensure that the sender’s monitoring is active and working.
¶ Successful Delivery to the Platform
After successful transmission, the invoice sender synchronously receives a so-called Business Transaction ID (BTID). This transaction ID enables the unique identification of the e-Invoicing transaction. If TecAlliance Support is needed, this ID must be provided for traceability (see also 3.3.2 Successful Delivery).
¶ Erroneous Delivery to the Platform
The invoice sender is responsible for erroneous deliveries to the platform for which he does not receive a transaction ID. In this case he must monitor and watch over the email notifications and file directory (Connect5), Webservice Response (Webservice) or e-Invoicing Monitor (Dynamics, SAP) and escalate the case (see also 3.4.1 Failed Delivery to the Platform).
¶ Transaction Log
Monitoring the the email address provided by the invoice sender for the case of an error or implementation and surveillance of monitoring with the help of the implemented transmission channel is mandatory for a working and stable error handling process.
If the invoice sender receives a transaction log for a failed transaction, he must actively respond to it. Depending on the error message, he must either resend the transaction or develop an individual solution scenario in cooperation with TecAlliance Support (see also 3.5 Transaction Log).
¶ 10.2.3 Error Correction and Resending
On request, the sender must correct or complete erroneous or missing data in cooperation with the invoice receiver or TecAlliance Support. If necessary, the invoice sender must resend the affected transaction(s).
If an invoice must be resent due to an error, the invoice sender must discuss changing the payment and discount deadlines for the invoices with the customer.
¶ 10.2.4 Data Completeness and Correctness
The e-Invoicing platform transmits the invoice information received from the invoice sender to the invoice receiver and any participating third parties (roaming, fiscal clearing, Aktivbank).
Responsibility for the invoice data, in particular for its completeness and correctness, lies with the invoice sender.
This is also so in the case of validation by the e-Invoicing platform. Validation cannot guarantee 100 percent correctness of the data but it greatly reduces the error rate. Additional manual labour and payment delays due to reclamations and invoice corrections can be avoided through validation. Responsibility for the content remains with the invoice sender.
¶ 10.2.5 Data Integrity
If the invoice sender sends his own PDF file in addition to the structured data, he must guarantee that the content of the PDF document matches that of the structured data.
In addition, the invoice sender is responsible as part of his due diligence to guarantee that the transmitted data is correct. He must also ensure that it matches the data in his bookkeeping, CRM and ERP systems and cannot be modified after transmission.
¶ 10.3 Requirements for the Invoice Receiver
¶ 10.3.1 Minimum Requirements for the Receipt of Invoices
The receipt of invoices is possible when at least one email address of the invoice receiver is known. Beyond this, the invoice receiver can select one or more receiving options for deeper integration.
For secure and reliable invoice delivery, receiving via Connect5, TecCom Portal, Webservice or an ERP component (SAP module) is always recommended. This is because the transmission of invoice data by email offers a target for scam and phishing attacks according to knowledge of the business partner and the attack vectors.
The different possibilities and requirements for the receiving channels are described in 2.1 Transmission Paths.
¶ 10.3.2 Documents That Cannot Be Processed
If invoice data was transmitted by TecAlliance that the invoice receiver could not process, then the invoice receiver must initiate the search for the cause. If necessary TecAlliance Support can be called to assist with advice (see also 3.4.2 Documents That Cannot Be Processed).
¶ 10.3.3 Uncollected Documents
The invoice receiver must take care that documents are reliably retrieved. If documents for invoice receivers with a connection via Connect5, MFT, Webservice or ERP component are not retrieved in time, the invoice sender receives the corresponding warning (see also 3.4.3 Uncollected Documents).
TecAlliance is not responsible for transmission paths of the invoice receivers (i.e. Internet connection, server availability, operation of receiving components). Delivery by TecAlliance is considered complete as soon as the configured documents have been made available at the agreed receiving channel (see also 3.3 Successful Transactions).
¶ 11. Business Relations
¶ 11.1 Setting Up Business Relations
In order to connect to a new business partner via e-Invoicing, a business relation must be set up between the invoice sender and the invoice receiver.
The business relation includes the ERP numbers needed for the routing; these must match the party numbers from the structured data. The combination of organisation settings and business relation is used to control the correct processing in the e-Invoicing process (workflow, visualisation, mapping, delivery options, fiscal clearance, etc.).
Setting up a business relation is performed in agreement between invoice senders and invoice receivers via the TecCom Portal, through TecAlliance Support or as part of a rollout project.
¶ 11.1.1 Reporting to TecAlliance Support by the Invoice Sender
An invoice sender can request new business relations from TecAlliance Support by using a template. The template can be given to the invoice sender during the implementation project or later supplied by TecAlliance Support.
The template must be completed with at least the name, email address and ERP numbers of the invoice receiver as well as delivery and processing options.
See also 13.2 Setting Up New Business Relations.
¶ Note on Entry of Email Addresses
If possible, no specific personal email addresses should be entered. Functional email addresses, to which numerous employees of the receiver have access if needed, are preferable. This is the only way to ensure that invoices are still delivered after a change of employees or that more than one employee can be informed.
Emails from the e-Invoicing platform are always sent from noreply@invoice.tecalliance.net. In Cloud Invoice sender organisations, the entry of a reply-to address is required. This means that the invoice sender must ensure that he gives an email address for responses from the receivers when sending invoices. The supplier must monitor this email address because invoice receivers may send emails to this address using the reply function of an email client.
¶ Note on Delivery Options
One or more delivery options for the invoice receiver must be entered into the template.
The desired form of invoice delivery should be clarified in advance with the receiver. As an alternative, the receiver should know through which channel and from which starting date he will receive invoices.
If no delivery option is entered, TecAlliance will set up invoice receipt by email.
If the invoice receiver already has other business relations and is set up for the receipt of invoices with a connection different from the delivery option given in the template, the current connection will be used. Such corrections are shown in the template.
For delivery options that require the installation of Connect5, ERP components or a Webservice connection, the invoice receiver should be informed of the costs in advance in order to avoid delays in setting up the connection.
¶ 11.1.2 Setup by TecAlliance Support
TecAlliance Support sets up the reported business relations. Single business relations are usually set up within a few working days. For larger quantities (from around 15 business relations), it is advisable to talk to TecAlliance Support in advance to ensure that they are set up quickly.
¶ 11.1.3 Testing and Activation by the Invoice Sender
The invoice sender is informed by email after setup of the business relations.
Setting up business relations is performed according to the four-eyes principle. After setting up the business relation on the e-Invoicing platform, the invoice sender himself must test and activate it.
If the entered data is not correct, the business relation may not be activated and TecAlliance Support must be informed.
The invoice sender receives access to the administration GUI for test purposes as part of the implementation project. He also receives the instructions to activate business relations.
¶ 11.2 Modifying Business Relations
Changes to a business relation such as e.g. updating an email address or changing the invoice receiver account number should be agreed to with the invoice receiver and TecAlliance Support.
In particular, changes in delivery options that could also have technical effects on the other party must be discussed with the business partner directly or through TecAlliance Support so that the partner can make the necessary changes to his systems.
¶ 12. Service Level Objectives
¶ 12.1 Basis
An SLO (Service Level Objective) is an agreement within an SLA (Service Level Agreement) about a certain metric such as availability or reaction time. The e-Invoicing SLOs are part of the e-Invoicing Service Description. They are based on the prerequisite TecCom SLA and therefore require it as an additional component.
¶ 12.1.1 Services in the Scope of the SLO
- Receiving of invoice data from the invoice sender
- Delivery of invoice data to the invoice receiver
- Processing of transactions
- Storage of transaction data
- E-Invoicing Webservices (TOM WSDL, SOAP WSDL, REST API)
- Transformation of invoice data (mapping)
- Signing of invoice documents
- Validation of structured invoice data
- Fiscal clearing
- Roaming processes and workflows
- PDF visualisation
- Long-term archiving
¶ 12.1.2 Services out of Scope of the SLO
- Components of the Connect5 specification
- Components of the Dynamics 365 specification
- Components of the TecCom Portal specification
- Components of the Order Core specification
- Components of the CMD specification
- Components of the SAP specification
- Components of the Returns & Warranty specification
- Availability of clearance platforms in CTC countries
- Availability of roaming networks
¶ 12.1.3. Requirements for the Customer
The customer must observe and comply with 10. Notes and Duties .
¶ 12.2 Service Availability
Availability applies to the e-Invoicing solution as a whole. “Cloud Invoice” or “legacy e-Invoicing (TecInvoice)” refers to the sum of the individual functions listed under 12.1.1 Services in the Scope of the SLO.
| Service | System Environment | Availability |
|---|---|---|
| Cloud Invoice | Productive | 99.7% |
| Legacy e-Invoicing (TecInvoice) | Productive | 99.2% |
| Eurolog Web UI | Productive | 98.5% |
| TecCom Portal UI | Productive | 99.4% |
¶ 12.3 Maintenance
As a rule, updates to the e-Invoicing solution can be executed without downtime thanks to serverless deployment. In individual cases, a maintenance window may be required in which the availability of one or more parts of the e-Invoicing may be interrupted for a time in order to perform activities necessary for platform operation.
Should there be an interruption in the availability of individual services, the delivery of data to the platform would still be possible but the processing would be delayed to the end of the maintenance window.
Maintenance windows (planned maintenance) are normally announced two weeks in advance.; in individual cases (hot fixes) the advance notice may be shorter.
Maintenance windows are announced on 13.3.2 TecAlliance Status Monitoring customers can also subscribe to email notifications there .
¶ 12.4 Deployment of a New Release Version
All hot fixes, error corrections, expansions and changes to the e-Invoicing solution are made with the deployment of a new release together with an update of the system version. Releases can be published for different reasons.
¶ 12.4.1 Eliminating Errors (Bugs)
Bugs are eliminated either through a planned release or a hot fix. In both cases, the function of existing features is not changed and the downward compatibility to the previous version is guaranteed.
¶ 12.4.2 Enhancement of Functions
As a rule, the enhancement of the e-Invoicing solution does not impair the previously available functionality but only extends it. The downward compatibility to the previous version is guaranteed.
If this should not be possible for a particular reason, e.g. because the legal requirements change in a country in which the customer is active, customers will be properly notified in due time. In these cases the customer and the salesperson or project manager will coordinate the extent, duration and implementation of any necessary measures.
¶ 12.4.3 Modification of Functions
As a rule, existing functionalities are not changed but only extended. The downward compatibility to the previous version is guaranteed as a rule.
If this should not be possible for particular reasons, e.g.. because the technical requirements of the product have changed, customers will be properly notified in due time. In these cases the customer and the salesperson or project manager will coordinate the extent, duration and implementation of any necessary measures.
¶ 12.4.4 Deactivation of Functions
The deactivation of functions is generally avoided but it can be necessary for reasons of economy, technological developments, information security or strategic decisions.
In these cases the changes in the product life cycle will be announced in the End of Lifecycle (EoL) Overview. Customers will also be properly notified in due time. The customer and the salesperson or project manager will coordinate the extent, duration and implementation of any necessary measures.
¶ 12.5 Backup & Recovery
Basically, backup & recovery plans are measures for an unlikely exceptional case such as e.g. a cyberattack (ransomware). As part of the ISMS (ISO/IEC 27001), security guidelines are continually tested and improved in order to prevent such an occurrence in advance. Backup and recovery plans are also implemented and practiced in order to recover and restart operations in case of emergency. The following values refer to recovery from a total failure, a scenario that hopefully never will occur.
A 100% recovery can never be achieved because data backups are always subject to a certain delay. This is why a data loss affects only the last transactions delivered to the platform before the outage.
The backup and recovery concept is based on a Business Impact Analysis (BIA) and corresponding Disaster Recovery Plans. As the recovery of all data from the long-term archive is more critical than configuration and transaction data, it is more extensively secured.
| Service | System Environment | RPO | FP |
|---|---|---|---|
| e-Invoicing (configuration, transactions) | Productive | 1 hour | 99.995% |
| e-Invoicing (processed documents) | Productive | 15 minutes | 99.997% |
| Long-term archive (Eurolog) | Productive | 15 minutes | 99.997% |
| Long-term archive (Cloud Invoice) | Productive | 8 minutes | 99.999% |
RPO = Recovery Point Objective (maximum date loss for an outage measured in time)
FP = File Persistency (calculated percentage of recoverable data for an outage based on the RPO)
¶ 13. Attachment
¶ 13.1 Customer Support and Availability
The availability and escalation levels for customer support are described in the TecCom Service Level Agreement (SLA) and in TecCom Customer Wiki. The access data to the TecCom Wiki and the TecCom SLA is provided to each customer at contract signing. Customers can also request access at any time.
¶ 13.2 Setting Up New Business Relations
New business relations can be set up through TecCom Support. The required template is available from TecAlliance Support.
¶ 13.3 Technical Availability
¶ 13.3.1 Service Level Objectives (SLO)
The technical availability of the e-Invoicing platform is specified in 12. Service Level Objectives.
¶ 13.3.2 TecAlliance Status Monitoring
With TecAlliance Status Monitoring, customers can see the status for the relevant solutions. They can also subscribe to status notifications by email.
¶ 13.4 End of Life Roadmap
As a rule, customers can continue to use components and formats after an EoL date at their own risk. After an EoL date, "Support" by TecCom will be terminated. Bug fixes, software maintenance and free support will no longer be offered.
TecCom may offer an extended phase of "Security Fixes Only" and/or "Extended Maintenance" for some components and formats.
TecCom Support will inform customers in advance of changes in the EoL status of individual components.
Detailed information can be found at End of Lifecycle (EoL) Overview | TecCom Wiki (tecalliance.net).
¶ 13.5 e-Invoicing Certifications
¶ ISO/IEC 27001:2022
The development, operation and maintenance of SaaS solutions for e-Invoicing are certified according to ISO/IEC 27001:2022.The strict guidelines of e-Invoicing ISMS ensure compliance with all criteria relevant to failure, information and data security. The guidelines guarantee the secure and reliable operation of the e-Invoicing solution for all customers and business partners.
¶ Audit Trail / Process Documentation
The audit trail / process documentation describes the processes, measures and controls regarding the exchange of electronic invoices. The contents of the process documentation cover the complete e-Invoicing service offering of TecAlliance.
The following processes are described in the process documentation:
- E-invoice process
- E-reporting process
- Archiving process
With TecAlliance as the provider, the process documentation closes the gap from the time the invoice is submitted by the invoice sender to the e-Invoicing platform until the invoice is transmitted to the invoice receiver from the e-Invoicing platform.
The process documentation serves as proof of an uninterrupted and verifiable process that conforms to the requirements for electronic invoices regarding: completeness, correctness, traceability, verifiability, immutability, order, timeliness, availability, readability, authenticity and authorisation.
The process documentation is part of the legal basis for original invoices in electronic form in any format that conform to tax law.
¶ ISAE 3402 Audit and Report
In 2017, TecAlliance GmbH received the report on the audit of the description and controls of the
e-invoicing process from a renowned international auditing firm. The audit was conducted in accordance with the International Federation of Accountants (IFAC) auditing standard ‘International Standard on Assurance Engagements (ISAE) 3402, Assurance Reports on Controls at a Service Organisation’.
The subject of the audit was the description of the service-relevant internal control system and the controls and control objective described in it. It refers to the service-relevant internal control system in the following areas:
- Sending an invoice in PDF format as an original invoice
- Generation of a legally valid electronic signature
- Generation of an electronic test protocol to check the signature
- Long-term archiving of an invoice
- Transmission of structured data (TXML 2.5)
- Various delivery options: E-Mail, Web Portal, TOMConnect/PullClient, integration in ERP (SAP)
- Sending an invoice in TXML format (original invoice), e.g. as in the original document process for central regulation with the Aktivbank AG
A report according to ISAE 3402 Type 1 was prepared describing the results of the audit. TecAlliance customers can see this report (contact: responsible salesperson).
¶ 13.6 Suppliers, Providers and Service Providers (Outsourcing)
External and internal suppliers and service providers are supervised as part of e-Invoicing ISMS (ISO/IEC 27001:2022). The strict guidelines of e-Invoicing ISMS ensure compliance with all criteria relevant to failure, information and data security. The guidelines guarantee the secure and reliable operation of the e-Invoicing solution for all customers and business partners.
¶ 13.7 Additional Documentation & Handbooks
All documentation, handbooks and guidelines for the connection to and use of e-Invoicing may be provided to the customer during the implementation project or at any time on request, whether they are specifically needed or not. Additional documentation is available for:
- Implementation of the legacy e-Invoicing SOAP Webservice
- Implementation of the legacy e-Invoicing TOM WSDL Webservice
- Implementation of the Cloud Invoice REST API
- Implementation of the SAP e-Invoicing Module
- Implementation of the Microsoft Dynamics 365 Module
- Installation and Configuration of Connect5
- Use of the TecCom Portal
- Country Specifications (Guidelines /Business Rules)
- Format Specifications (Guidelines /Business Rules)
- Aktivbank Process and Format Requirements
- GOLDA Process and Format Requirements
- VeR-Roaming specification v1.1
¶ 13.8 Glossary
| Term | Category | Description | Reference |
|---|---|---|---|
| Aktivbank | Data Processing | Invoice regulator for the central regulation process | 8. Central Settlement with Aktivbank |
| AS/4, AS/2, OFTP2, SFTP | Data Transmission | Data transmission protocols for MFT | 2. Data Transmission | 2.1.2 Managed File Transfer (MFT) |
| automotive aftermarket | General | Automotive replacement part market | |
| AWS | General | Amazon Web Services is an American cloud-computing provider that was founded in 2006 as a subsidiary of the online warehouse Amazon. | |
| B2B | General | Business-to-business describes the trade in services and goods among companies. | |
| clearance platform/CTC platform | Regulatory | Describes a country’s IT system from which data can be transmitted or on which it can be received. The data can be processed on it if appropriate, especially for fiscal clearing. | 7. Fiscal Clearance |
| clearing/fiscal clearing/clearance | Regulatory | Transmission and. if applicable, approval of invoice data by a finance authority on its CTC platform | 7. Fiscal Clearance |
| Cloud Invoice | General | Cloud Invoice is part of the e-Invoicing system landscape. It was developed in a serverless environment on AWS and cloud native. Cloud Invoice replaces legacy e-invoicing (TecInvoice). | 1. The e-Invoicing Solution | 1.3.1 Cloud Invoice and Legacy e Invoicing (previously “TecInvoice”) |
| Connect5 | Data Transmission | Middleware components from TecCom for the quick and easy integration and connection to the e-Invoicing solution | 2. Data Transmission | 2.1.1 Middleware Components |
| CTC mandate | Regulatory | Continuous Transaction Control describes the requirement of a country for clearing processes. Usually with centralised or decentralised transmission of an invoice to the platform of the finance authorities. | 7. Fiscal Clearance |
| data format | Document Format | A machine-readable format with structured data as required for electronic invoice delivery | 4. Data Formats |
| decentralised CTC model | Regulatory | CTC mandate of a country that does not require approval of an invoice before it may be delivered to the actual receiver | 7. Fiscal Clearance |
| DIN EN 16931 | Document Format | DIN EN 16931 is a semantic data model with business rules for e-Invoicing processes. It was published by the European Commission. It currently contains three authorised compatible formats and the rules for conversion to the corresponding syntaxes. |
|
| e-invoicing mandate | Regulatory | Requirement of a country that invoices must be exchanged electronically in a structured data format | 7. Fiscal Clearance |
| e-Invoicing system / e-Invoicing platform | General | Collective term for all features and processes that TecAlliance offers as e-Invoicing. This includes all parts except for those specially installed on the customer side. | |
| EDI | Document Format | Electronic Data Interchange is the electronic exchange of data. According to context, also used for EDIFACT, the data standard in Europe and Asia. | 4. Data Formats |
| single invoice | Document Format | TecCom defines a “single invoice” as an invoice document that has either a maximum of one order reference and multiple delivery references or a maximum of one delivery reference and multiple order references. | 10. Notes and Duties | 10.1.4 Notes on the Sending of Consolidated Invoices |
| element | Document Format | The smallest item of information in the EDI or XML standard | 4. Data Formats |
| receiver organisation | General | An entity set up on the e-Invoicing system for the invoice receiver or a participating third party to receive document data | 10. Notes and Duties |
| receiving channel | Data Transmission | A path for data transmission from the e-Invoicing platform to the receiver | 2. Data Transmission |
| receiving component | Data Transmission | A path for data transmission from the e-Invoicing platform to the receiver that requires implementation or installation on the customer side. | 2. Data Transmission |
| ERP component | Data Transmission | A module or an extension for the connection to the e-Invoicing platform that is directly integrated in the customer’s ERP system | 2. Data Transmission | 2.1.4 ERP Component |
| ERP system | General | Enterprise Resource Planning system is a collective term for all customer systems in which business partners are managed and document data is generated or processed. | |
| field length limitation | Document Format | A limit in the maximum character length of a field’s content as stated in the Guidelines or business rules | 4. Data Formats |
| GENA (EESPA) | General | Global Exchange Network Association (GENA, previously EESPA). Association with the goal of harmonising the e-invoicing landscape in Europe. It represents the interests of invoice senders and invoice receivers. | Home - GENA |
| business relation | General | A business relation between a supplier and a customer. In the context of the e-Invoicing solution, it is a technical connection between sender and receiver organisations on the platform to enable data exchange. | 11. Business Relations |
| business rule | Document Format | A rule that describes how data in a format must be structured or displayed. A business rule can also describe the specifications or limitations of a business process. | 4. Data Formats |
| guideline | Document Format | A collection of rules to describe a data format | 4. Data Formats |
| inbound | Data Transmission | Incoming transactions, e.g. receiving an invoice via roaming or from a CTC platform and then delivering it to the receiver. | 2. Data Transmission | 2.2 Roaming |
| ISAE | Regulatory | International Standard on Assurance Engagements | 13. Attachment | ISAE 3402 Audit and Report |
| ISMS | Regulatory | Information Security Management System describes the safeguarding and documentation of all required processes in a company to guarantee information security. | 13. Attachment | ISO/IEC 27001:2022 |
| ISO/IEC 27001 | Regulatory norm requirements for an ISMS | ||
| cardinality | Document Format | A rule that describes how often an element may be repeated in a data format | 4. Data Formats |
| customer portal | Data Transmission | Collective term for all graphical user interfaces (Web UI) in which customers can administer transactions, documents, organisations and business relations. |
9. Invoice Portal (Web UI) |
| country format | Document Format | A country’s individually developed (or extended) data format that may or must be used in that country. | 7. Fiscal Clearance | 7.2 Country Formats and CIUS |
| long-term archive | Data Processing | System with a user interface for the legally valid revision-proof long-term archiving of document data. | |
| legacy e-Invoicing (TecInvoice) | General | Legacy e-Invoicing is part of the e-invoicing system landscape. It will be replaced by Cloud Invoice. | 1. The e-Invoicing Solution | 1.3.1 Cloud Invoice and Legacy e Invoicing (previously “TecInvoice”) |
| mapping | Document Format | Describes the conversion or transformation of data from one data format to another data format. | 4. Data Formats | 4.1 Mapping/Transformation |
| MFT | Data Transmission | Managed File Transfer is a technology that makes possible the secure, efficient and reliable transmission of data. Companies use MFT software as a secure alternative to the use of insecure protocols such as FTP and HTTP for file transmission. | 2. Data Transmission | 2.1.2 Managed File Transfer (MFT) |
| middleware component | Data Transmission | Middleware is software located between an operating system and the applications running on it. In principle, middleware functions as a hidden translator layer. It enables distributed applications to communicate and manage data. | 2. Data Transmission | 2.1.1 Middleware Components |
| MS Dynamics 365 | Data Transmission | A module for the connection to the e-Invoicing platform that is directly integrated in the customer’s ERP system | 2. Data Transmission | 2.1.4 ERP Component |
| Order 2 Invoice Flow | General | Includes all business processes from the initial availability enquiry through ordering, order confirmation, delivery note/delivery to invoice. If handling of returns is added, then it is called "Order 2 Invoice 2 Returns" or "Order 2 Returns". | |
| Original invoice / invoice original | Regulatory | The invoice document that entitles the bearer to deduct input tax | 6. Original Invoice & Copy |
| Outbound | Data Transmission | Outgoing transactions, e.g. sending an invoice to a roaming partner or a CTC platform | 2. Data Transmission | 2.2 Roaming |
| p7s | Document Format | *.p7s files are PKCS#7 data: This is the case of a detached signature. This means that the signed data and the signature are saved in two separate files. | 5. PDF and Signature |
| Document Format | The Portable Document Format is a platform-independent file format for documents. | 5. PDF and Signature | |
| PKCS | Document Format | Public Key Cryptography Standards | 5. PDF and Signature |
| platform | General | An IT system for the sending or receiving of data. On a platform, data can also be processed when indicated. | |
| invoice receiver | General | This is the invoice receiver of an invoice according to tax law (addressee). Depending on context it can also be just the receiver. | 10. Notes and Duties |
| invoice copy | Regulatory | Non-binding copy of the invoice document that entitles the bearer to input tax deduction | 6. Original Invoice & Copy |
| invoice portal | Data Transmission | Collective term for all graphical user interfaces (Web UIs) in which transactions, documents, organisations and business relations can be managed |
9. Invoice Portal (Web UI) |
| invoice sender | General | This is the invoicing party for an invoice. Depending on context it can also be just the sender. | 10. Notes and Duties |
| REST API | Data Transmission | Webservice for the connection to the e-Invoicing platform. | 2. Data Transmission | 2.1.3 Webservice |
| revision-proof | Regulatory | The term “revision-proof” refers to the revision-proof archiving in electronic archive systems. In Germany these systems must meet the requirements of German laws. These laws include the Commercial Code (§§ 239, 257 HGB), the General Fiscal Law (§§ 146, 147 AO), the principles of orderly EDP-supported bookkeeping systems (GoBS), the principles of orderly keeping and storage of books, records and documents in electronic form as well as data access (GoBD) and additional tax and trade law specifications. The term is oriented to the understanding of revision from a business standpoint. It regards information and documents that require or are worthy of storage. Source: German Wikipedia ”revisionssicher” | 6. Original Invoice & Copy | 6.1.2 Revision Proof Archiving |
| roaming | Data Transmission | Roaming includes all workflows that include the receiving from or sending to another network, provider or additional third party. A roaming workflow can be combined with other workflows if needed. | 2. Data Transmission | 2.2 Roaming |
| back-integration | Data Transmission | Describes the receiving of invoice documents by the invoice sender after they have been processed on the e-Invoicing platform. This is done so that the documents can be saved in the sender’s own long-term archive. | 10. Notes and Duties | 10.1.2 Archiving of the Legally Valid Original Document |
| SaaS | General | Software as a Service (SaaS) is a cloud-based software model that delivers applications to the end user through an Internet browser. SaaS providers host services and applications that customers can access as needed. | |
| collective invoices | Document Format | TecCom defines “collective invoices” as invoice documents with both multiple order references and multiple delivery references. |
10. Notes and Duties | 10.1.4 Notes on the Sending of Consolidated Invoices |
| SAP module | Data Transmission | Module for the connection to the e-Invoicing platform that is integrated directly into the customer’s ERP system | 2. Data Transmission | 2.1.4 ERP Component |
| SDK | Data Transmission | The Software Development Kit helps customers with the integration and implementation of the components for the connection to the e-Invoicing platform. | |
| semantic data model | Document Format | A structural specification for the representation and organisation of data in a machine-readable format without the specification of a syntax | 4. Data Formats | 4.4 EN 16931 |
| sender component | Data Transmission | A path for data transmission from the invoice sender to the e-Invoicing platform that requires implementation or installation on the customer side | 2. Data Transmission | 2.1 Transmission Paths |
| sender organisation | General | An entity set up on the e-Invoicing system for the invoice sender or, if applicable, a third party to deliver document data to the platform | 10. Notes and Duties |
| serverless | General | Serverless computing is a method to make available back-end sevices based on their actual use. With a serverless provider, users can write code and make it available without having to worry about the infrastructure it is built on. | |
| SOAP WSDL | Data Transmission | Webservice for the connection to the e-Invoicing platform with TecCom Open Messaging | 2. Data Transmission | 2.1.3 Webservice |
| subset | Document Format | An expansion of the requirements described in the Guidelines and Business Rules to a data format and, if applicable, the related business rules | 4. Data Formats | 4.3 e Invoicing Subsets |
| TecCom Portal | General | TecCom Portal is the customer-facing graphical user interface (Web UI) from TecCom. Orders, invoices and returns can be viewed and administered here. | TecCom |
| TOM WSDL | Data Transmission | Webservice for the connection to the e-Invoicing platform with TecCom Open Messaging | 2. Data Transmission | 2.1.3 Webservice |
| TOMConnect | Data Transmission | TOMConnect is a receiving component with which invoice data can be easily integrated into the system of the invoice receiver. The TecAlliance platform sends the invoice data via Push Webservice to TOMConnect. This saves the data in a directory on the invoices receiver's system. The receiver can import the data from there into his ERP system. | 2. Data Transmission |
| transaction | Data Processing | Data set and processes for the processing of one or more documents through the e-Invoicing platform | 3. Data Processing | 3.2 Monitoring |
| transaction ID | Data Processing | Unique identifier (primary key) for a transaction. | 3. Data Processing | 3.3.1 Successful Delivery to the System |
| transaction log | Data Processing | Protocol file with information about all process steps executed during a transaction | 3. Data Processing | 3.5 Transaction Log |
| TXML | Document Format | TecCom XML is the data format for the automotive aftermarket developed by TecAlliance. | 4. Data Formats |
| transmission channel | Data Transmission | A path for data transmission from/to the e-Invoicing platform | 2. Data Transmission |
| VeR | Data Transmission | Electronic Invoice Association, German: Verband elektronische Rechnung e.V. | Verband elektronische Rechnung (VeR) » Startseite |
| audit trail documentation (process documentation) | Regulatory | Complete documentation of the procedure to ensure the integrity and authenticity of the invoice sender and document data | 13. Attachment | Audit Trail / Process Documentation |
| Web UI | General | Graphical user interface that is executed in a browser | |
| workflow | Data Processing | A closed process chain to reach a process goal from the invoice sender to the invoice receiver (e.g. central regulation or fiscal clearance in a particular country). | 2. Data Transmission |
| centralised CTC model | Regulatory | CTC mandate of a country that requires approval of an invoice before it can be delivered to the actual receiver. In some cases, the CTC platform itself may make the delivery. | 7. Fiscal Clearance |