Independent IFS Cloud practice · Expert notes
Duplicate supplier invoice detection in IFS Cloud: why exact match misses most real duplicates, and how to design a fuzzy-match rule that does not flag legitimate near-matches
Key takeaways
- An exact-match check on invoice number only catches the least common form of duplicate: a genuine re-key of the identical reference. Retyped, re-scanned and dual-channel duplicates carry a different reference string entirely and pass straight through.
- A fuzzy-match rule needs four dimensions at once, supplier, amount, date window and a normalised reference, because any single dimension alone produces either near-total noise or near-total blindness.
- Credit-and-rebill pairs are the single largest source of false positives in a naive fuzzy rule. They share supplier, near-identical amount and a tight date window with a genuine duplicate, and only the sign of the amount and the document type separate them.
- Reference normalisation, stripping formatting characters, leading zeros and channel-specific prefixes before comparison, is what makes the fuzzy match usable rather than academic.
Ask a controller how their duplicate invoice check works and the answer is almost always some variant of “it checks the invoice number against what we already have on file.” That check is real, it runs, and it catches almost nothing, because a genuine duplicate rarely arrives with the identical string in the invoice reference field. It arrives re-keyed with a transposed digit by a supplier whose AP clerk typed it twice, or it arrives on two channels, a PDF by email and a paper copy by post, each processed by a different person who never compared notes. Meanwhile a rule loose enough to catch those cases will just as happily flag a credit note followed by a corrected re-invoice, which is not a duplicate at all and which, if blocked, delays a legitimate payment and damages a supplier relationship for no reason. Building a duplicate detector that is actually worth trusting means understanding exactly why exact match fails, what a fuzzy match needs to compare, and how to keep the false-positive rate low enough that AP does not learn to override every hold the system raises.
1.What an exact-match check actually does, and why it misses most duplicates
A standard duplicate check compares the incoming invoice’s supplier reference against references already recorded for that supplier and flags an identical string. It runs at invoice entry or on import, and where it fires it is genuinely useful: it stops the case where the same document, unaltered, is keyed or scanned in twice. The problem is that this is the least common way a real duplicate actually enters the system.
In practice, most real duplicates carry a reference that is close to, but not identical to, the one already on file. A supplier’s AP clerk re-keys the invoice by hand after an EDI feed silently failed, and mistypes one character. The same invoice arrives twice through two different intake channels, an email attachment and a supplier portal upload, and each channel’s OCR or parsing step normalises the reference slightly differently, one keeping a leading zero, the other stripping it. A supplier resubmits after a query, appending “-R” or “REV1” to the original reference to indicate a revision, when in substance nothing about the underlying charge changed. In every one of these cases, a string-exact comparison sees two different values and passes both invoices straight through to payment.
2.The four dimensions a fuzzy-match rule needs together
A workable fuzzy match cannot rely on any single signal in isolation. Each dimension on its own either produces overwhelming noise or misses the cases exact match already misses:
- Supplier. Restricting comparison to invoices from the same supplier account is the cheapest and most defensible filter, and it should always be the outer boundary of the search rather than scanning the whole ledger.
- Amount, within a small tolerance. Comparing amount alone within a supplier will flag every recurring subscription or standard-rate service invoice as a near-duplicate of the last one, so amount only earns weight when combined with the other three signals, not on its own.
- A bounded date window. Two invoices from the same supplier for a similar amount six months apart are almost certainly unrelated; the same pairing inside a window of a few days to a couple of weeks is a meaningfully different signal and deserves scrutiny.
- A normalised reference. Not an exact string match, but a comparison after stripping punctuation, leading zeros, whitespace and known channel-specific prefixes or suffixes, then measured with a similarity function such as edit distance rather than equality.
The combination matters more than any individual threshold. A pair that scores high on three of the four dimensions and weak on the fourth is a stronger candidate for review than a pair that scores moderately on all four, and a rule that simply sums independent scores without weighting the reference-similarity signal more heavily tends to under-flag the cases that matter most: same supplier, same amount, close date, and a reference that is clearly the same invoice retyped.
3.A worked fuzzy-match rule
The pattern below is illustrated as generic, PL/SQL-flavoured pseudocode using aliases rather than an assertion about a specific release’s exact schema, intended to show the shape of the join and the scoring logic rather than exact field names:
| Signal | What it tells you |
|---|---|
| candidate.supplier_id = existing.supplier_id | The hard filter. Every comparison below only runs within this pairing, keeping the search space small and the false-positive base rate manageable. |
| ABS(candidate.amount - existing.amount) <= :amount_tolerance | A small absolute or percentage tolerance, not exact equality, to catch rounding and minor currency-conversion differences between a retyped invoice and the original. |
| ABS(candidate.invoice_date - existing.invoice_date) <= :date_window_days | Bounds the comparison to a plausible resubmission or duplicate-entry window rather than the supplier’s entire invoice history. |
| EDIT_DISTANCE(NORMALISE(candidate.reference), NORMALISE(existing.reference)) <= :ref_distance_threshold | The normalised-reference similarity score. Normalisation strips separators, leading zeros and known prefix or suffix patterns before the distance function runs, which is what lets a one-character retyping error still score as a near match. |
| candidate.doc_type = existing.doc_type AND SIGN(candidate.amount) = SIGN(existing.amount) | Excludes credit notes and reversal documents from matching against the original invoice they relate to, which is the section 4 trap. |
A pair that satisfies the supplier, amount and date conditions and clears the reference-distance threshold is a hold candidate, not an automatic block. The distinction matters operationally: an automatic block on a fuzzy match, unlike an exact match, will eventually catch a legitimate near-match and stop a real payment, so the rule should route to a review queue with the matched pair shown side by side, not silently reject the second invoice.
4.The trap: credit-and-rebill pairs, and other legitimate near-matches
A credit-and-rebill pair is the single most common false positive a fuzzy matcher generates once it starts working well enough to catch real duplicates. A supplier issues a credit note against an incorrect invoice and then reissues a corrected invoice for the same or a very similar amount, from the same supplier, usually within days. On supplier, amount and date alone, this pair is indistinguishable from a genuine duplicate. It is only distinguishable because one document is a credit, carrying a negative amount or a distinct document type, and the other is a standard invoice, and because the reference on the credit note typically points back at the original invoice it is correcting rather than resembling the reissued one.
A rule that compares absolute amount without checking sign, or that does not filter by document type before scoring reference similarity, will flag this pair every time, and it will do so for one of the more routine, legitimate exception flows in accounts payable. The fix is not a looser threshold, it is an explicit document-type and sign condition ahead of the fuzzy comparison, as shown in the last row of the table above.
A second, subtler near-match worth excluding deliberately is a recurring service invoice with a genuinely stable amount, a maintenance contract or a subscription billed monthly at an identical rate. Two consecutive months of an identical amount from the same supplier will satisfy the amount and date conditions trivially. What separates it from a duplicate is that the reference itself changes predictably, an incrementing invoice number or a period-coded suffix, and a normalisation step that strips the wrong part of that reference, the incrementing digit rather than a formatting artefact, will accidentally collapse two genuinely different invoices into a false match. Normalisation rules need to be tuned per reference format, not applied as one blanket regular expression across every supplier.
5.How to build the fuzzy-match detector, in order
- Start with the exact-match population and measure its recall. Run the existing exact check against a sample of known real duplicates found manually or through an audit, and confirm for yourself how few it actually catches before proposing anything more complex.
- Profile the reference formats in use, per supplier. Reference conventions vary widely: some suppliers zero-pad, some prefix with a site or division code, some append revision suffixes. A single global normalisation pattern will underperform a small set of supplier-specific rules.
- Set the amount tolerance and date window from real data, not intuition. Look at the time gap and amount delta on genuine historical duplicates you can identify, and size the thresholds around what actually occurred rather than a round number that feels safe.
- Add the document-type and sign exclusion before scoring reference similarity. This single condition removes the largest source of false positives, as covered in section 4, and should not be treated as an optional refinement added later.
- Route matches to a review queue, not an automatic block. Present the candidate pair side by side with both amounts, dates and references visible, and let a human confirm before anything is held from payment.
- Track the override rate by reviewer and by supplier. A high override rate on a specific supplier usually means that supplier’s reference format needs its own normalisation rule, not that the whole detector needs loosening.
- Wire the confirmed-match logic to a Custom Event on invoice entry. Once thresholds are tuned against real data, the same scoring logic can run at the point of entry rather than as a periodic batch report, catching a likely duplicate before it is approved for payment rather than after, built inside the Extensibility Framework against the standard supplier invoice entity.
6.Frequently asked questions
Why does an exact-match duplicate invoice check miss most real duplicates?
Because a genuine duplicate rarely arrives with the identical reference string already on file. It is usually re-keyed with a small typo, submitted through a second channel that formats the reference differently, or resubmitted with a revision suffix appended. All of these produce a different string, which an exact-match comparison treats as unrelated.
What are the four signals a fuzzy-match rule needs?
Supplier, an amount within a small tolerance, a bounded date window, and a normalised reference compared by similarity rather than equality. Any one of these used alone either produces overwhelming noise or misses the cases exact match already misses; the combination, weighted toward reference similarity, is what makes the rule usable.
Why do credit-and-rebill pairs get falsely flagged as duplicates?
Because they share supplier, a near-identical amount and a tight date window with a genuine duplicate. Only the document type and the sign of the amount distinguish a credit note followed by a corrected reissue from an actual duplicate invoice, so the matching rule needs an explicit document-type and sign condition ahead of the fuzzy comparison, not a looser threshold.
Should a fuzzy-match duplicate hit block payment automatically?
No. Unlike an exact match, a fuzzy match will eventually catch a legitimate near-match, so it should route to a review queue with both documents shown side by side rather than silently blocking payment. Track the override rate by supplier to identify which reference formats still need their own normalisation rule.
7.About the author
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Want your duplicate invoice logic reviewed before it costs you a real payment?
If your current check is either missing real duplicates or flagging so many credit-and-rebill pairs that AP overrides it by habit, the scoring logic is usually the fix. A short scoping conversation is enough to tell you which.