Automated invoice matching in procure-to-pay using Integration Broker led to 90% reduction in manual effort

SCM Infor SCM
, , , , , , , ,
1

We’re experiencing issues with our automated invoice matching workflow in Infor SCM’s supplier collaboration module. The system is failing to detect duplicate invoices from the same supplier, leading to potential overpayments.

Our duplicate detection logic seems to be working inconsistently. The invoice matching criteria should flag invoices with identical amounts and dates from the same supplier ID, but we’re seeing duplicates slip through. The supplier ID validation appears to be case-sensitive, which might be part of the problem.

Here’s the current matching configuration:


SupplierMatch.caseSensitive=true
InvoiceMatch.tolerance=0.00
DuplicateWindow.days=30

Has anyone dealt with similar duplicate detection issues? We need to tighten up the matching criteria before month-end close.

2

For the tolerance question - it depends on your currency and volume. We use 0.01 tolerance for USD transactions which handles rounding issues without being too permissive. Your bigger issue is the matching logic architecture. You need composite key matching that includes supplier ID (normalized), invoice number, amount (with tolerance), and date range. The current three-field approach is inadequate for enterprise-scale duplicate prevention in supplier collaboration workflows.

3

We had the exact same issue last quarter. The problem was that our invoice matching criteria weren’t comprehensive enough. We were only comparing amount and date, but not invoice number or PO reference. Duplicates with different invoice numbers but identical amounts were getting through. You need to expand your matching fields beyond just the basic three.

4

One thing nobody’s mentioned - are you validating supplier master data consistency? We discovered that some suppliers were registered multiple times with slight variations in their records, which broke our duplicate detection completely. Run a supplier data quality audit first.

5

I’ve seen this before. The case-sensitive supplier ID validation is definitely a problem. Many suppliers submit invoices with slight variations in their ID formatting - sometimes uppercase, sometimes mixed case. Your matching criteria are too strict for the tolerance level. Consider normalizing supplier IDs to uppercase in your validation logic before comparison. Also, check if your duplicate detection window of 30 days is appropriate for your business cycle.

6

Thanks for the feedback. I reviewed our workflow configuration and you’re both right about the limitations. The case sensitivity is causing about 15% of our false negatives. I’m also concerned about our zero tolerance setting - is that too restrictive? Should we allow a small variance for rounding differences?