Accounts Payable invoice IDoc fails from vendor portal due to duplicate check

Our vendor portal integration sends invoice IDocs (INVOIC02) to S/4HANA 1909 but we’re experiencing failures due to duplicate invoice detection. The IDoc reference fields are populated correctly with unique invoice numbers, but SAP’s duplicate check configuration keeps flagging legitimate invoices as duplicates causing invoice posting delays.

The vendor master data is configured properly and vendors can submit invoices through the portal, but when multiple invoices from the same vendor arrive within a short timeframe, the second and subsequent invoices are rejected.

Error from transaction WE02:

<IDOC STATUS="51">
  <ERROR>Invoice 2025-INV-00234 already
  exists for vendor 100234</ERROR>
  <FIELD>XBLNR</FIELD>
</IDOC>

We’ve checked the IDoc reference fields configuration and XBLNR contains unique values. The duplicate check logic seems overly aggressive. How should we configure the duplicate check to allow legitimate invoices while still preventing true duplicates?

Don’t modify the vendor’s invoice number in XBLNR - that needs to remain as the vendor entered it for audit and reconciliation purposes. Instead, use the reference fields (XREF1, XREF2) for portal-specific unique identifiers. Also ensure your IDoc includes the invoice date (BLDAT) with full timestamp precision, not just date. This helps SAP distinguish between invoices submitted on the same day. The duplicate check can be configured to use these additional fields through customizing.

Let me provide comprehensive resolution addressing all three critical areas:

1. IDoc Reference Fields Configuration: The INVOIC02 IDoc structure has multiple reference fields that must be properly populated to support accurate duplicate detection:

Key fields in segment E1EDK01 (Document Header):

  • XBLNR: Vendor’s original invoice number (must remain unchanged)
  • BELNR: SAP accounting document number (assigned by SAP, not in inbound IDoc)
  • XREF1: Reference field 1 (use for portal transaction ID)
  • XREF2: Reference field 2 (use for portal submission timestamp)
  • XREF3: Reference field 3 (use for vendor portal session ID)

Enhance your vendor portal integration to populate:

<E1EDK01>
  <XBLNR>2025-INV-00234</XBLNR>
  <XREF1>PORTAL-TXN-789456123</XREF1>
  <XREF2>20250719090534</XREF2>
  <XREF3>SESS-VND100234-456</XREF3>
  <BLDAT>20250719</BLDAT>
  <BLDAT_TIME>090534</BLDAT_TIME>
</E1EDK01>

Critical: Include invoice date with time precision (BLDAT + BLDAT_TIME fields). SAP’s duplicate check can use timestamp to distinguish invoices submitted minutes apart.

2. Duplicate Check Configuration in SAP: Transaction OBCD (Duplicate Invoice Check) controls which fields SAP compares:

Current issue: Standard configuration compares:

  • Company code + Vendor + Fiscal year + Reference (XBLNR) + Amount

With zero tolerance, two invoices with:

  • Same vendor (100234)
  • Same fiscal year (2025)
  • Similar amounts (e.g., 1000.00 and 1000.00)
  • Even with different XBLNR values

Might still trigger duplicate check if amounts match exactly.

Recommended Configuration Changes:

a) Adjust amount tolerance in OBCD:

  • Navigate: IMG → Financial Accounting → Accounts Payable → Business Transactions → Incoming Invoices → Maintain Tolerances (Invoice Verification)
  • Set amount tolerance to small value (e.g., 0.01) rather than zero
  • This allows invoices with identical amounts to post if other fields differ

b) Configure time-based duplicate check:

  • In OBCD, enable ‘Time Interval’ option
  • Set to 1 day (86400 seconds)
  • This means SAP only considers invoices duplicates if submitted within 24 hours
  • Invoices from same vendor on different days won’t trigger false positives

c) Enhance duplicate check criteria:

  • Transaction OBCD → Advanced Settings
  • Enable ‘Check Reference Fields’ option
  • Configure SAP to include XREF1 and XREF2 in comparison logic
  • This ensures portal transaction IDs are considered in duplicate detection

d) Vendor-specific duplicate check settings:

  • In vendor master data (FK02), field XDEZV controls duplicate invoice check
  • Values: blank (no check), ‘1’ (warning), ‘2’ (error)
  • Consider setting to ‘1’ (warning) for vendors who frequently submit similar invoices
  • This allows AP team to review and override false positives

3. Vendor Master Data Optimization:

Verify and enhance vendor master configuration:

a) Duplicate invoice check indicator (FK02):


// Pseudocode for vendor master review:
1. Query table LFA1 for all portal-enabled vendors
2. Check field XDEZV (duplicate check indicator)
3. For vendors with frequent submissions:
   - Set XDEZV = '1' (warning only)
4. For high-risk vendors:
   - Keep XDEZV = '2' (hard error)
5. Document vendor-specific settings

b) Payment terms and reference fields:

  • Ensure vendor master has correct payment terms (ZTERM)
  • Verify vendor bank details are current
  • These affect how SAP processes incoming invoices

c) Vendor portal registration data:

Maintain custom table linking:

  • Vendor number (LIFNR)
  • Portal user ID
  • Submission preferences
  • Duplicate check override authority

Complete Implementation Steps:

Step 1: Enhance IDoc generation in vendor portal

Modify portal backend to include unique identifiers:


// Pseudocode for IDoc enhancement:
1. When vendor submits invoice:
   a. Generate portal transaction ID: PORTAL-TXN-{timestamp}-{random}
   b. Capture submission timestamp: YYYYMMDDHHmmss
   c. Get vendor portal session ID
2. Build IDoc segment E1EDK01:
   a. XBLNR = vendor's invoice number (unchanged)
   b. XREF1 = portal transaction ID
   c. XREF2 = submission timestamp
   d. XREF3 = portal session ID
   e. BLDAT = invoice date (YYYYMMDD)
   f. BLDAT_TIME = invoice time (HHmmss)
3. Send enhanced IDoc to SAP

Step 2: Configure SAP duplicate check

a) Transaction OBCD:

  • Set amount tolerance: 0.01 (allows slight variations)
  • Enable time interval: 86400 seconds (24 hours)
  • Activate reference field checking

b) Create custom Z-function module for enhanced duplicate logic:


// Pseudocode for custom duplicate check:
FUNCTION Z_INVOICE_DUPLICATE_CHECK.
  // Called from IDoc processing
  1. Extract invoice data from IDoc segments
  2. Query table BKPF for existing invoices:
     - Same vendor (LIFNR)
     - Same fiscal year (GJAHR)
     - Same reference (XBLNR)
  3. If matches found:
     a. Compare XREF1 (portal transaction ID)
     b. If XREF1 differs -> NOT duplicate
     c. Compare XREF2 (timestamp)
     d. If time difference > 300 seconds -> NOT duplicate
  4. Return: IS_DUPLICATE (true/false)
ENDFUNCTION.

c) Assign custom function to IDoc processing:

  • Transaction WE19: Create IDoc test
  • Transaction WE57: Link function module to message type INVOIC
  • Use user exit EXIT_SAPLEINM_001 to inject custom duplicate check

Step 3: Implement monitoring and alerting

Create custom report to track duplicate check issues:


// Report: Z_INVOICE_DUPLICATE_MONITOR
1. Query table EDIDS (IDoc status records)
2. Filter: STATUS = '51' AND MESSAGE like '%duplicate%'
3. For each failed IDoc:
   a. Extract vendor, invoice number, amount
   b. Query BKPF for potential duplicate
   c. Compare reference fields (XREF1, XREF2, XREF3)
   d. Determine if true duplicate or false positive
4. Generate report with recommendations:
   - True duplicates: Alert AP team
   - False positives: Auto-reprocess with override

Step 4: Vendor communication and training

  • Update vendor portal help documentation
  • Explain invoice number uniqueness requirements
  • Provide guidelines for invoice submission timing
  • Create FAQ for duplicate invoice errors

Immediate Resolution for Your Current Issue:

The error shows invoice ‘2025-INV-00234’ for vendor 100234 is being rejected. To resolve:

  1. Check if this invoice actually exists:

SE16 -> Table BKPF
Filter: LIFNR = 100234
        XBLNR = 2025-INV-00234
        GJAHR = 2025
  1. If invoice exists:

    • True duplicate: Contact vendor to verify
    • False positive: Check if amounts/dates are identical
  2. If invoice doesn’t exist:

    • Bug in duplicate check logic
    • Check if previous IDoc with same XBLNR failed partially
    • Query table EDIDS for IDoc history
  3. Override and reprocess:


// Transaction WE19:
1. Load failed IDoc (from WE02)
2. Modify XREF1 to append '-RETRY-01'
3. Reprocess with duplicate check override
4. Monitor in WE02 for successful posting

Long-term Best Practice:

Implement a hybrid approach:

  • Keep standard duplicate check active (OBCD with reasonable tolerance)
  • Add custom enhancement using reference fields (XREF1/2/3)
  • Vendor-specific settings for high-volume submitters
  • Regular monitoring and false positive analysis
  • Quarterly review of duplicate check configuration effectiveness

This ensures legitimate invoices process smoothly while maintaining controls against true duplicates and fraud.

From portal development side, we can adjust what data we send in the IDoc. Currently we populate XBLNR with the vendor’s invoice number as they enter it. Should we append additional unique identifiers like portal submission timestamp or session ID to make each XBLNR truly unique from SAP’s perspective? Or would that cause issues with vendor reconciliation since they won’t recognize the modified invoice number?