The EDI business process ‘INVOIC invoice’ is used across all industries for the transmission of invoice data and is widely used in both the retail and automotive industries as a standard EDI process.

The process is generally considered to be relatively demanding because EDI specification catalogs call for a comparatively large amount of EDI data content. In the light of the immense savings potential that the major market players expect from digitized inbound invoices, a certain pressure is often exerted on suppliers to map this process using EDI technologies. Depending on the scenario, the figures for the potential cost reduction through EDI processes for inbound invoices compared to manual entry vary between 5 and 40 euros —per document!

The EDI message type ‘INVOIC invoice’ has different names in the various EDI formats:

The requirements for the content of EDI invoices are very much partner-specific. The EDI documentation of the required invoice content reflects the semantic requirements of the different merchandise management systems on the customer’s side. As the process design for processing EDI invoice data is very heterogeneous, the specifications can vary greatly depending on the invoice recipient. The presentation of discounts, surcharges, and deductions at header and item level, and rounding issues are just some of the aspects that must be considered and correctly presented when implementing EDI invoices on the sender’s side. Even in areas with strong standardization tendencies—such as the task force AK-Handel—you will find that retail chains like Metro require an MGE supplier number in the EDI invoices, while this data element naturally plays no role at Edeka, Rewe, and the like.

There is little to no room for deviation from the specifications defined in the various EDI documentation for correct electronic invoice exchange. On the receiver’s side, there are almost always automated validation programs that first check the syntactic correctness of the EDI document before the electronic invoices are actually processed in the underlying ERP system; a semantic plausibility check then follows. If the EDI invoice passes pre-processing as part of the inbound EDI process without issues, the invoice is paid. If one of the check criteria is violated, the invoice is rejected, the supplier receives an automated error notification, and the corresponding payment deadline is typically postponed to a later date. This can result in significant monetary losses, especially in the case of higher invoice volumes.

Softzoll supports its customers not only on a syntactic level by ensuring the correct outbound invoice format. Softzoll is also able to implement a vice versa plausibility check of the EDI invoices. The outbound EDI invoices are first transferred to the transaction database of the EDI system and collected there. Next, the invoice data generated from the ERP system undergoes an upstream plausibility check.