M8 108 — M8 108 — Check if Invoice Already Entered

M8 108 tells you that SAP believes the supplier invoice may already have been entered. In classic Logistics Invoice Verification this check is commonly encountered in MIRO and related invoice processes. The message is not proof that the new document is always a true duplicate; it means the configured duplicate-check criteria matched an existing accounting document closely enough to trigger the control. Depending on configuration and product version, the message can be handled as a warning or an error. That distinction is important because changing severity affects process control but does not change how the duplicate comparison itself works.

The obvious cause is a genuine duplicate invoice with the same supplier reference and relevant comparison values. Other cases arise when suppliers reuse invoice references, when reference numbers are truncated or standardized by an interface, or when multiple legitimate invoices share dates and similar values. Duplicate-check customizing can also be too broad or too narrow for the business process. In S/4HANA Cloud and automated invoice scenarios, online and background processing can use different message numbers or handling, so a control that works in MIRO may not behave identically in automation. Cancelled documents and historical settings can also influence what the system considers during the check.

Open the proposed invoice and identify supplier, company code, reference number, invoice date, amount and purchase-order context. Search existing supplier/accounting documents for the same reference and verify whether an earlier document is active, reversed or cancelled. Check the supplier/business-partner setting for duplicate-invoice checking where applicable. Review the Logistics Invoice Verification configuration that defines duplicate checks and inspect message control for M8 108. If the issue occurs only in background or Fiori processing, compare the exact message returned there with the online MIRO message because SAP provides additional duplicate-related message numbers for automated processing.

If the invoice is genuinely duplicated, stop the second posting and resolve the business duplicate with Accounts Payable. If it is a legitimate invoice, first determine which comparison field caused the collision. Correct the supplier reference or upstream interface mapping only when the source document itself is wrong. If the business has intentionally chosen to allow possible duplicates for review, set the appropriate message severity through supported invoice-verification message configuration rather than modifying standard code. In S/4HANA Cloud, use the corresponding configuration activity instead of assuming classic transaction behavior. Retest both online and background invoice creation because controls can differ by processing channel.

The most dangerous shortcut is to convert M8 108 from error to warning simply because users are blocked. That may allow genuine duplicate supplier invoices and create payment, tax and reconciliation problems. Another weak approach is to disable duplicate checking in the supplier master globally to solve one exceptional supplier case. Both actions reduce a financial control without understanding the collision. The better fix is to establish whether the invoice is truly duplicated, identify the comparison criterion that matched, and then adjust master data, interface behavior or message severity only with Finance approval.

Accounts Payable owns the business decision on whether an invoice is duplicate. MM/LIV configuration owners are responsible for duplicate-check settings and message severity. Master-data teams may own the supplier duplicate-check indicator. Integration teams become involved when external invoice platforms or OCR solutions transform or reuse invoice references. ABAP should be the last resort; standard configuration already supports the core control. For production incidents, involve Finance controls before changing severity because the technical setting directly affects a preventive control around duplicate liabilities and payments.

Do not test only with a copied invoice number and assume that proves the entire rule. Duplicate checking can involve several fields and processing variants. Do not ignore leading zeros, reference normalization, document reversal status or company-code scope. In cloud or automated processing, do not assume M8 108 is the only relevant duplicate message. If you change message severity, document the business approval and retest invoices created manually, in background and through interfaces. Finally, distinguish a duplicate supplier invoice from a duplicate accounting document created by downstream technical retry; the remediation is different.