We’re experiencing EIB inbound integration failures in our order-to-cash process. Customer invoice loads are failing with duplicate detection errors, even though the invoices are unique in our source system.
The batch processing runs nightly and started failing after we upgraded to R1 2023. Error logs show:
ERROR: Duplicate Invoice Number detected - INV-2025-0347
Batch Status: FAILED
Records Processed: 0 of 2,847
Our EIB error handling doesn’t seem to catch this properly - the entire batch fails instead of processing valid records. We need the integration to skip duplicates and continue processing, but can’t find the right configuration. Has anyone dealt with duplicate invoice detection in EIB inbound loads?
Based on your description, you need to address all three focus areas systematically:
EIB Error Handling Configuration:
The R1 2023 release changed how EIB handles validation errors. You need to modify your integration service settings. In Workday Studio or your integration definition:
This allows the batch to continue processing valid records while logging errors for duplicates.
Duplicate Invoice Detection Enhancement:
Implement a pre-processing validation step. Before your EIB load, add a custom validation using the Customer Invoice web service:
// Query existing invoices
GET /Customer_Invoices?Invoice_Number={number}
// Filter source data to exclude matches
// Log duplicates to separate error file
This prevents duplicates from reaching EIB entirely.
Batch Processing Optimization:
For your nightly batch processing, implement these changes:
Add retry logic with exponential backoff - If the batch fails, retry individual failed records after the main batch completes
Implement checkpointing - Track which records have been successfully processed so you can resume from the last successful point
Split large batches - Instead of loading 2,847 records at once, split into chunks of 500-1000 records. This isolates failures to smaller subsets
Enable detailed logging - Configure your EIB to log each record’s processing status. This helps identify which specific invoices are causing issues
Root Cause Investigation:
Based on your error pattern, the duplicate detection is likely caused by one of these scenarios:
Incomplete previous loads: Check Integration Event reports for any loads stuck in ‘In Progress’ status from previous nights
External ID mismatches: Verify your invoice number mapping uses consistent formatting (leading zeros, prefixes, etc.)
Concurrent processing: Ensure no other integrations are loading invoices simultaneously
Implementation Steps:
First, query Integration Events to identify any incomplete loads and clean them up
Modify your EIB integration settings to enable partial success mode
Add the pre-validation step to check for existing invoices
Implement batch splitting and checkpointing
Test with a small subset (50-100 records) before running the full nightly batch
Monitoring:
Set up alerts for:
EIB batch completion status
Duplicate detection count (should be tracked separately from failures)
Processing time trends (to catch performance degradation)
This comprehensive approach will make your integration more resilient while properly handling duplicates without failing the entire batch. The key is moving from an all-or-nothing approach to graceful degradation with detailed error tracking.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this before. The duplicate detection is likely happening at the business object level, not the EIB level. Check your Customer Invoice business object configuration - there’s usually a unique constraint on invoice number that’s causing the hard failure. You need to modify your EIB integration to handle duplicates more gracefully.
We had the exact same issue last quarter. The problem is that EIB’s default error handling stops the entire batch when it encounters a duplicate. You need to enable partial success mode in your integration configuration. Go to your EIB definition and look for the error handling section - there should be an option to ‘Continue on Error’ or ‘Allow Partial Success’. This will let valid records process while logging duplicates separately. Also check if your source system is actually sending duplicates due to retry logic.
Thanks for the suggestions. I checked the EIB definition but can’t find a ‘Continue on Error’ setting. Our EIB is configured with standard validation rules. Is this setting in the integration attributes or somewhere in the business object configuration? Also, we verified the source data and there are definitely no duplicates being sent.
Tested this on our EIB inbound integration in Workday R1 2023 and setting Validation_Mode to Partial_Success allowed valid invoices to process while duplicate errors were logged separately.
The issue might be timing-related. If your batch processing runs nightly and the previous night’s load didn’t complete properly, you could have orphaned records in Workday that are triggering the duplicate check. I’d recommend checking your integration history to see if there are any partially completed loads. You can query the Integration Event report filtered by your EIB integration name to see the status of previous runs. If you find incomplete loads, you may need to manually clean up those records before rerunning your batch.
This is a known behavior change in R1 2023. The duplicate detection logic became stricter in this release. What you need to do is implement a pre-validation step in your integration flow. Before the EIB load, query existing invoices using the Get Customer Invoices web service to check for duplicates. Filter out any matches in your source data before sending to EIB. This prevents the hard failure at the EIB level.
Another thing to check - are you using external IDs or Workday IDs in your EIB mapping? If you’re using external IDs and they’re not matching properly, Workday might think you’re creating a new invoice when you’re actually trying to update an existing one. This would trigger the duplicate invoice number constraint. Review your ID mapping in the EIB template carefully.