Found a duplicate MM invoice? Here's how to troubleshoot the reason

[giovani_quadros]

Since 2020, I've been working in the Product Support for MM Invoice Verification area and handled many different cases on which customers report unexpected behaviors on their systems. One of the most common behaviors that are reported is that a duplicate supplier invoice was posted and the system should have prevented it, but it was not prevented for some reason.

The good news is that the reason is frequently related to a missing configuration or, in some cases, a missing note implementation. If you have come to this blog post because an unexplained duplicate invoice was posted to your system, it is very likely that you will find a simple solution in the next minutes.

Although KBA 2036775 has an overview of the duplicate invoice check, there are some other factors that should be clarified regarding duplicate invoices. This blog post will also clarify those points.

Possible reasons behind duplicate invoices

In all cases I've worked on regarding this context so far, the duplicate invoice could be explained by one of the reasons below. Why should your case be an exception?

Here are (nearly) all root causes and how you can check for them:

1 - Is the duplicate check active in vendor master data?

When dealing with vendors, there's a fundamental thing you need to check to avoid any headaches. First, you need to make sure that the vendor has the duplicate check turned on. To do that, just look for the 'Chk double inv.' flag in transaction XK02 (for ERP systems) or BP (for S/4HANA). That's it!

2 - Duplicate-check criteria

Is the vendor correctly set? Time to dive into the nitty-gritty of detecting duplicate invoices. I'll break it down for you, no worries.

First, we need to look at the criteria set at the company-code level. To manage this, we use a transaction called OMRDC, which has three flags that do the trick.

• Company code: This flag controls the scope of the duplicate check within a specific company code. If it's on, you can create similar invoices under different company codes without them being flagged as duplicates.


• Invoice date: Now, this flag focuses the duplicate check on the invoice document date (not the posting date). When it's off, invoices with similar content but different dates can get picked up as duplicates.


• Reference: This is the big one! The main indicator used to spot duplicate invoices. If an invoice has the same reference as another (and other criteria align), the duplicate is detected.

Got it? Right, now please keep this couple of notes in mind as well, as the duplicate-check logic gets a bit tricky now:

Note 1:

If the 'Reference' check is turned off, the duplicate check switches to an amount basis:

  IF t169p-xxblnr IS INITIAL.

    i_wrbtr_c = i_wrbtr.

    CONDENSE i_wrbtr_c.

    CONCATENATE 'AND wrbtr = ''' i_wrbtr_c '''' INTO code. "#EC NOTEXT

If you aren't an ABAP expert, you might not understand the piece of code above from function module MRM_FI_DOCUMENT_CHECK. But don't worry, it's not difficult to understand it.

It basically means that, if reference flag (XXBLNR) is disabled (INITIAL), the invoice amount (WRBTR) will be used as a criterion.

Note 2:

Watch out for these fields—they're non-configurable for detecting duplicate invoices:

• Vendor (LIFNR)


• Currency (WAERS)

If an invoice belongs to a different vendor or was posted with a different currency, it's automatically off the duplicate radar.

3 - Did the original invoice create an accounting entry on BSIP table?

At the FI level, the system performs the duplicate check by looking at the accounting documents in the BSIP table. But what does that mean for you?

Well, when you post that original invoice, here's what you need to do to check for duplicates:

1. Grab the accounting document number, company code, and fiscal year of the original invoice.


2. Now, head over to the BSIP table and search for an entry that matches the details of the original invoice.


3. If you find a matching entry in BSIP, the invoice can be successfully detected as a duplicate.

Couldn't find it? There's a little twist here. Some posting keys won't create BSIP entries, which means no duplicate check is possible in those cases.

This sneaky behavior also affects MM invoices. So, if you encounter such a situation, no need to panic. It's just the way the system works.

KBA 2868149 has further information on that point.

4 - Is the duplicate check programmed to send error messages?

Okay, we've got everything set up for detecting duplicate invoices, but there's more. Depending on how the message configuration is done, the system might find a duplicate invoice but choose not to take any action. Let me explain what's going on.

If all the settings we talked about earlier (sections 1 to 3) are good to go, we're in the basic scenario for detecting duplicate invoices. But here's the kicker:

The system can be a bit misleading sometimes. It might actually find a duplicate invoice but decide to do nothing about it. Why? Because the message it should send to warn you about the duplicate is switched off or set as a warning. And a warning will let you know about the duplicate, but it won't stop you from posting the invoice if you really want to.

To strongly prevent duplicates, go to transaction OMRM and ensure that the following messages are set as error messages:

• M8 108: Check if invoice already entered under accounting doc. no. & &


• M8 462: Check if invoice already entered as logistics inv. doc. number & &

5 - Invoices from automatic processes

We're now moving to specific scenarios which may lead to unexpected duplicates.

First, let's talk about how to identify those invoices that come from automatic processes. From the invoice header data on RBKP table, field IVTYP lets you know if the invoice came from an automatic process. For example, type 4 refers to EDI and type B refers to BAPI.

If the invoice was posted from Ariba, it is very likely that the invoice has one of these IVTYP values.

5.1 - Is note 2689288 applied?

Now, pay attention: If the invoice came from an automatic process, duplicate invoice check is not available in standard for these cases, so you absolutely need to have a special SAP Note in place:

2689288 - Check for duplicate invoices for automatic processes

Not sure if the note is implemented? A quick check is to view the beginning of function module MRM_DUPLICATE_INVOICE_CHECK.

If you can find the following DATA lines above the STATICS lines, it means that the note is implemented and the system is ready to detect duplicate invoices:

  DATA: lv_error         TYPE abap_bool,                    "2689288

        lv_msgno         TYPE msgno,                        "2689288

        lv_msgno_prot    TYPE symsgno,                      "2689288

        lv_default_msgty TYPE symsgty.                      "2689288



  STATICS: f_old_belnr LIKE s_rbkp-belnr,

           f_old_gjahr LIKE s_rbkp-gjahr.

If you can't find those lines, then you need to implement the note to prevent further duplicates.

5.2 - Is the background duplicate check programmed to send error messages?

Even if you've got note 2689288 in place, the manual steps of the note might not be applied.

In short, the following messages related to background check need to be set as error messages in OMRM:

• M8 804: Inv. not automatically created, potential duplicate exists (acc doc & &)


• M8 805: Invoice not automatically created, potential duplicate exists (inv. & &)

The reason is that they might be playing it cool because they are switched off as per standard settings. So, it's up to you to make them shout by explicitly configuring them as error messages in transaction OMRM.

6 - Was the invoice posted via Fiori app 'Import Supplier Invoices'?

That Fiori app post invoices on a background process.

Guess which messages should be configured: M8 804 and M8 805.
Time to apply the same configuration as section 5.2.

This scenario is explained in KBA 3114715 - Import Supplier Invoice: Duplicate Check.

7 - Are you creating a credit memo instead?

Did you know that duplicate check for credit memos is not enabled in standard?

The key to enable it is SAP Note 305277 - Check for duplicate credit memos.
But watch out! As it is a modification note, there are some orientations to efficiently handle these cases. If you aren't aware of them, you can find them in SAP Note 170183.

What to do next?

Alright, we've covered all the bases for ensuring that the duplicate invoice check is all set and ready to go!

Now, here's the good news: If everything's in place and you've confirmed the checks we just seen, the duplicate check should be running like a well-oiled machine.

If, by any chance, you notice an invoice slipping through the duplicate check without getting flagged, then you have an atypical case due to database inconsistencies or other unexpected behaviors.

In these cases, just reach out and create a SAP Support case. My colleagues and I will be on the case, ready to dig deep and troubleshoot what might have happened.