Expense management software: catch duplicates before payout

If you approve employee claims for a company of 50 to 500 people, run several legal entities, or mix corporate cards with out of pocket claims, this page is for you. If you are choosing your first expense app for a team of five, it is not.

A duplicate expense is a claim that pays the same business cost twice, either because the same receipt reached finance through two channels or because one employee submitted it twice in two different shapes. Expense management software does check for duplicates, but the check has documented boundaries: vendors publish them, and almost every duplicate that survives to payment sits just outside those boundaries. The practical question is therefore not whether your tool detects duplicates. It is which duplicates your tool was never designed to see, and what control you place in front of the payment run to catch those.

Key takeaways

• Oracle Fusion Expenses documents its duplicate algorithm as checking expenses created by the same employee over the last six months, and marking only unsubmitted expenses as duplicates of submitted ones.
• SAP Concur states that its Duplicate Transaction Check rule evaluates only the claimant and does not look across several employees' claims, and that it reads the details entered rather than the receipt attached.
• In the same Concur documentation, two itemized parent entries with identical expense type, date and amount trigger no exception at all.
• GBTA research with HRS, published October 2015, puts 19 percent of expense reports as containing errors or missing information, at an added cost of 52 dollars and 18 minutes to correct each one.
• Since 1 September 2026 French companies must be able to receive structured supplier invoices, which creates a second arrival channel for expenses an employee may also claim by hand.

What your expense management software actually compares

Start with what the vendors themselves publish, because it is precise and rarely read.

Oracle documents the mechanism in Detection of Duplicate Expenses for Fusion Financials. The algorithm "checks for all the expenses created by an employee in the last six months and detects duplicate expenses based on the expense fields, such as amount, date, currency, expense type, merchant". Two boundaries are stated in the same paragraph: the window is six months, and "only the expenses that aren't submitted are marked as duplicates of submitted expenses".

SAP Concur publishes its criteria through its own community. The Duplicate Transaction Check compares entries that share expense type, date and amount. Asked whether the rule can stop the same receipt being claimed by several employees, a Concur community manager answered plainly in November 2023: "the rule only evaluates the claimant. It does not look across a number of employees' claims." A second answer in the same thread adds that the rule "looks at the individual's expense reports and looks at the details entered, not the receipt attached".

The same documentation contains a case that surprises most finance teams. Concur classifies entries as regular, child (an itemization) or parent (an entry that has itemizations). The exception fires on regular against regular, child against child, and child against regular. It fires on one side only when a parent meets a regular or a child. And for parent against parent, it "triggers for none of the entries". A hotel folio itemized into room, breakfast and parking, submitted twice, is a parent against a parent.

Read that right column as a specification rather than a complaint. Each line is a duplicate that will clear approval, clear the payment run, and leave no exception behind it.

Six ways the same expense gets paid twice

1. The corporate card feed and the manual claim

The card charge arrives automatically. The employee, unsure whether it landed, also keys the receipt as an out of pocket expense. On a domestic charge the amounts match and the rule catches it. On a foreign charge they do not. A Concur customer described the mechanism precisely in June 2024: the bank converts the card charge at its rate, the expense tool converts the cash claim at another, so "even though the transaction currency and amount remain the same, the reimbursement amount differs due to the varying exchange rates used". Their own post payment analytics caught those claims. The pre payment rule did not.

2. The itemized folio against its own lines

A hotel stay is captured once as an itemized folio and once as separate room and meal entries, or twice as two itemized folios. Concur's published matrix says the parent against parent case triggers nothing. Nobody involved is acting in bad faith, and nothing on the report looks wrong.

3. One receipt, two claimants

Four colleagues have dinner. Two of them photograph the bill. Both claim it. Because the rule evaluates one claimant at a time and reads typed fields rather than the image, neither claim is flagged. This is the single most common duplicate in a team that travels together, and it is structurally invisible to every tool that scopes detection to the individual.

4. The supplier invoice and the employee claim

An employee pays a 200 euro hotel bill personally. The hotel, applying the rules now in force, issues a structured invoice in the company's name that lands directly in the company's invoice channel. Finance pays the supplier. Finance also reimburses the employee. France Num, the French government's digital guidance service, names this risk in its own words: the company "risque de payer la facture au fournisseur, ET de rembourser la note de frais au salarié", and calls it the biggest danger of the transition for an SMB. The same guidance notes that an invoice received and not explicitly rejected is treated as accepted, so silence is a decision.

5. Per diem on top of the receipt

A travel day is compensated by a flat allowance and the same meal is also claimed with its receipt. The two entries share neither amount nor expense type, so no field level rule will connect them. The link is a policy rule about a date and a person, not a match between two rows.

6. The same cost in two entities

A shared team lunch, a training session, a subscription paid by one entity and recharged to another. The claim sits in one company's expense tool and the invoice sits in another's ledger. No duplicate check spans the two, because no single system holds both sides. This is a reconciliation problem before it is an expense problem, and it is the reason internal controls belong above the tools rather than inside one of them.

How to detect duplicate expense claims that the native rule misses

Every case above breaks one assumption: that a duplicate is an exact field match inside one employee's history in one system. Replace that assumption and the controls follow.

1. Match across claimants, not within one. Compare merchant, date and amount across the whole population for the period, then surface pairs for human review. The pairs are rare enough to review by hand and impossible to find by eye.
2. Match on tolerance bands, not on equality. A duplicate created by two currency conversions or two mileage calculations is a near match. A band on the amount plus an exact merchant and a date window finds what an equality test cannot.
3. Read the receipt, not only the form. The document carries a merchant, a timestamp, a ticket number and a total. Two claims built on the same underlying ticket share those, whatever was typed into the fields.
4. Cross the sources before the payment run. The expense tool, the card feed and the supplier invoice queue have to be compared against each other. That comparison is the only control that catches case 4, and it has to happen before both payments leave.
5. Hold a rule set, not just a matching engine. Per diem against receipt, mileage against a travel booking, subscription against a card charge: these are policy checks expressed once and run on every batch.

The distinction that matters is timing. A post payment audit finds duplicates and turns them into a recovery conversation with an employee, which costs goodwill and usually more than the amount involved. The same finding one day earlier is a line that never gets paid. Phacet's position across its catalogue is that control belongs before the payment clears, not in the audit after it.

What good looks like in numbers

Two reference points frame the size of the problem without inflating it.

On process cost, GBTA research conducted with HRS and published on 20 October 2015 remains the most quoted measurement: the average cost of processing a single expense report was 58 dollars, 19 percent of reports contained errors or missing information, and each of those cost an extra 52 dollars and 18 minutes to correct. The error rate is the number to keep. One report in five needs a human to touch it again.

On fraud, the ACFE's Occupational Fraud 2026: A Report to the Nations analysed 2,402 cases and more than 3.4 billion dollars of losses, with a median loss of 104,000 dollars per case and a median duration of 12 months before detection. Asset misappropriation, the family that contains expense reimbursement schemes, appeared in 90 percent of cases. Duplicate claims are rarely the largest fraud in an organisation. They are among the most persistent, because each one is small enough to clear approval on its own.

A control layer above the expense tool, not a replacement for it

None of this argues for changing software. Your expense tool collects receipts well, routes approvals well and posts to the ledger well. Its duplicate check does exactly what its documentation says it does. The gap is not inside any one system, it is between the expense tool, the card feed and the invoice queue, and no vendor owns that space by design.

That is where a control layer sits. The Phacet agent that runs expense report controls automatically reads what your systems already produce, applies the rules you already wrote, and returns the exceptions rather than the whole file. It turns receipts and statements into auditable tables first, then matches across sources rather than inside one of them. The matching itself is semantic rather than literal, which is what allows a near match on amount with an exact match on merchant to surface as one pair: that is the job of reconciliation across systems with the reasoning exposed. Every step is traced and timestamped, so an exception can be shown to an auditor or an accountant as evidence rather than as an assertion.

The same mechanism already runs on the neighbouring problem. Supplier invoices arriving twice are caught by the control that stops a supplier invoice being paid twice, and card spend that quietly funds two subscriptions for the same tool is caught by the agent that monitors card spend and flags duplicate SaaS tools. Expense duplicates are the third face of one control, not a separate product.

On general purpose assistants, since the question comes up: Claude and ChatGPT are remarkable tools, but they do not know your suppliers, your expense policy, your entities or your accounting rules, they produce no audit trail, and they do not connect to your mailbox or your SFTP. Phacet's 40+ agents were built on 100+ finance deployments in production, which is where the six cases above come from.

The order of magnitude such controls surface is worth knowing. At Astotel, a group of 18 Paris hotels, moving from sampling to line by line checking on supplier invoices surfaced 400 euros of billing errors per month on a single supplier, close to 5,000 euros a year. Valérie, Directrice Achats, puts it simply: "I spot errors I would never have seen on my own." The detail is in what Astotel found by checking line by line. At Smartbox, reconciling payments against invoices ran four times more productively once the matching was automated, and each use case reached production in six weeks.

From detection to prevention

Detecting a duplicate means finding a payment that already happened. Preventing one means knowing, on the morning of the payment run, that no line in the batch pays a cost that another line, another employee or another supplier invoice is already paying. The first is an audit finding. The second is a control.

The distance between them is a week of setup and a decision about where the check runs. A first agent reaches production in under two weeks at Phacet, tested on your real claims, and plans start at 299 euros per month. If the question you want answered is which of your own claims would have been caught, that is the right thing to run it on first: see the control run on your own expense data.

Frequently asked questions

What are duplicate claims?

Duplicate claims are two or more submissions that seek payment for a single business cost. They arise when one employee submits the same receipt twice in different shapes, when two employees claim the same shared bill, or when a cost reaches finance through both an expense report and a supplier invoice. Most are errors rather than fraud, and both cost the same amount.

How to handle duplicate invoices?

Block the second one before payment rather than recovering it afterwards. Match every incoming invoice against the supplier, amount, date and invoice number already in the ledger, and against open expense claims for the same cost. Flag near matches as well as exact ones, since a rekeyed number or a rounded amount defeats an equality test. Route the flagged pair to a human for one decision.

How to record an expense that will be reimbursed?

Record it as a company expense with its recoverable tax when the employee incurs it, and as a payable to that employee until reimbursement clears. Keep the receipt attached to the entry, since it is the document a tax or social security audit asks for. The reimbursement itself settles the payable and touches no expense account, which is what keeps the cost from being booked twice.

How are reimbursed expenses treated in accounting?

The cost belongs to the company, not to the employee who advanced it. The expense hits the relevant charge account on the date it was incurred, recoverable tax is separated out, and the amount owed to the employee sits as a liability until paid. Treating the later reimbursement as a fresh expense is one of the quieter ways the same cost ends up recorded twice.

How well does the duplicate expense flag catch duplicate claims?

Within its documented scope it is reliable, and that scope is narrow. Oracle checks one employee's last six months on matching fields. Concur compares expense type, date and amount for a single claimant, reads typed details rather than the receipt, and raises nothing when two itemized parent entries match. Anything crossing employees, sources or entities needs a control outside the expense tool.