skip to Main Content

INVOIC

Cross-industry standard message type for the transmission of invoice data

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:

Message type ‘INVOIC invoice’ in the different EDI formats

  • UN/EDIFACT invoice: INVOIC
  • ANSI X.12 invoice: ANSI X12 810
  • VDA invoice: VDA 4906
  • VDA invoice: VDA 4938 global INVOIC
  • PDF invoice: ZUGFeRD
  • ODETTE invoice: INVOIC
  • XML invoice: invoice etc.

Individual requirements for EDI invoice content

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.

Incorrect EDI invoices lead to payment delays

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.

Correct formats through upstream plausibility checks

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.

Example criteria for a plausibility check

The following are examples of checks according to specified content-related conditions (for inbound and outbound invoices).These test conditions can be customized.

Base values check invoice receipt/issue

  • The sender of the file is missing in field.
  • The recipient of the file is missing in field.
  • The consecutive numbering of the data record in the document in field LinNum is missing.
  • The invoice no. is missing.
  • The invoice type is missing.
  • The invoice date is missing.
  • The service provision date is missing.
  • The delivery note no. is missing.
  • The delivery note date is missing.
  • The buyer’s order no. is missing.
  • The buyer’s order date is missing.
  • The applicable VAT rate is missing.
  • The tax category is missing (S = standard rate; E = tax-exempt).
  • The currency is missing.
  • The invoice total is missing.
  • The total item amount is missing.
  • The total tax amount is missing.
  • The taxable amount is missing.

Involved

  • The supplier’s GLN is missing.
  • The buyer’s GLN is missing.
  • The recipient’s GLN is missing.

Additions/deductions at header level

  • The code for the type of surcharge/discount is missing (DI = discount, EAB = early payment discount, FC = freight charges).
  • The costing level is not specified.
  • The amount to be added/deducted is missing (unsigned).
  • The percentage to be added/deducted is missing (unsigned).
  • The amount to be added/deducted must be specified without sign.
  • The percentage to be added/deducted must be specified without sign.

Position

  • The unit of measure of the invoiced quantity is missing.
  • The unit of measure of the quantity is missing without calculation.
  • The unit of measure of the consumer units per invoiced container is missing.
  • The unit of measure of the consumer units per invoiced display is missing.
  • The unit of measure of the displays is missing in the invoiced items.
  • Only one method may be applied, either gross or net amounts.

Additions/deductions at item level

  • The code for the type of surcharge/discount is missing (DI = discount, EAB = early payment discount, FC = freight charges).
  • The costing level is not specified.
  • The amount to be added/deducted is missing (unsigned).
  • The percentage to be added/deducted is missing (unsigned).
  • The percentage to be added/deducted must be specified without sign.
  • The amount to be added/deducted must be specified without sign.

Totals check – sum check

  • Sum of amounts to be added/deducted
  • The sum of amounts to be added/deducted is missing.

Total item amount

  • The item total in the document does not equal the sum of all items’ gross amounts.
  • The item total in the document does not equal the sum of all items’ net amounts.

Taxable amount

  • The specified taxable amount is not correct.

Total tax amount

  • The total tax amount (100.NP2_3) was not calculated correctly.

Total amount of invoice

  • The total invoice amount is incorrect.

Avoidance of payment defaults through intelligent plausibility criteria

Each individual EDI invoice—and, if required, an associated collective EDI invoice—is checked against the stored criteria. If a violation of the plausibility criteria is detected, the affected document is suspended and an error message is generated. All valid documents that conform to the stored frame parameters are further processed, converted, and sent to the invoice recipient via the selected EDI communication channel. This procedure prevents the entire invoice dispatch process via EDI from failing due to a faulty document, or the entire invoice block from being rejected by the EDI partner. It is ensured that at least all correct documents are processed and settled by the recipient of the EDI invoices, thus avoiding complete non-payment.

Plausibility check at database level

This plausibility check is performed by an encapsulated entity at database level within the Softzoll EDI technology. Since this is not embedded in the corresponding conversion logics on the ERP or EDI side, the plausibility check can be ported and reused across individual application areas. It can, for example, be used for the global EDI invoice process, for a partner-specific adaptation, or for individual requirements of a special invoice recipient.

Back to overview
Questions about EDI?
 +49 (0)30 2100235-30
Mon - Fri, 9 a.m. - 5 p.m.
Leave us a message!
We will get back to you immediately;

 to the contact form
Back To Top