How Duplicate Invoices Slip Through Indian AP Teams — And How to Stop Them

The vendor emails the invoice on March 2nd. Your purchase head WhatsApps a photo of the same invoice on March 8th, asking for a payment update. Both enter your AP queue. Both look legitimate. Both get processed. Six weeks later, the vendor calls to say they received two payments. This is the most common duplicate invoice scenario in Indian mid-market AP — not sophisticated fraud, just two channels delivering the same document to a team with no automated deduplication.

How Duplicate Invoices Enter Indian AP Systems

Duplicates arrive through four routes. Same invoice, multiple channels: email, WhatsApp, courier, and the vendor's portal all feeding the same PDF into different inboxes at different times. Same invoice, slight variation: a vendor re-sends with a different invoice number because the first "didn't go through" — but the original was already processed. A credit note that triggers a replacement invoice, where both the original and the replacement get paid. And internal errors: two branches of the same company receiving the same supplier invoice and processing it independently, because there is no cross-branch visibility in Tally.

The last scenario is particularly common for companies with regional offices. Each branch maintains its own Tally company. A vendor who invoices both the Mumbai and Pune offices for overlapping scope may get paid twice — neither branch knows about the other's transaction.

What Composite Matching Actually Checks

For vendors under the e-invoicing mandate (₹5 crore+ aggregate turnover), the IRN is the cleanest deduplication signal. An IRN is a unique 64-character code generated by the IRP for every valid invoice — no two legitimate invoices from the same vendor can share one. If the same IRN appears twice in your AP system, one of them is a duplicate. Full stop.

For vendors not under the mandate — which includes many smaller, long-standing suppliers — deduplication requires composite matching: GSTIN + normalized invoice number + invoice date + total amount. "Normalized" matters here: "INV-2024-0371" and "INV2024371" are the same invoice number with different formatting. A matching system that requires exact string equality will miss this.

Tolerance thresholds also matter. If a vendor re-issues an invoice for ₹4.18 lakh after originally billing ₹4.2 lakh due to a credit adjustment, these are not duplicates — they are related transactions. The matching logic needs to distinguish between a re-issued invoice and a re-sent one. Getting this wrong in either direction either misses duplicates or blocks legitimate invoices.

When Duplicate Patterns Become Signals

A single duplicate is an operational error. The same vendor triggering duplicate flags three times in 90 days is a pattern worth investigating regardless of whether any money has actually left your account.

Most AP teams only track duplicates that resulted in a double payment. The more useful signal is tracking attempted duplicates: invoices that were blocked before payment. Four blocked duplicates from the same vendor in one quarter — even if caught correctly each time — warrants a conversation with that vendor about their billing process. Or more.

The controls that reliably prevent duplicate payments: IRN-based matching for mandated vendors, composite matching for all others, cross-branch invoice visibility for multi-location companies, and a rule that the vendor master is the single source of truth — not the PDF that arrived in a WhatsApp message.

Tally has basic duplicate detection, but it operates at the Tally company level. A business processing invoices across multiple branches, or receiving invoices through both Tally entries and a separate email inbox, needs deduplication that runs before the invoice enters any ERP — not after.

The question worth asking is not just "did we pay this invoice twice?" It is: "what percentage of our invoices have we never checked for duplicates at all?"