Expense and Card Data as a Discovery Source

The second source every programme should use, and the one that requires the most manual effort to make sense of.

What to extract

Corporate card transactions, all of them, for at least twelve months.

Accounts payable, for annual invoices that never touch a card.

Expense reimbursements, where individuals paid personally and claimed it back. This category catches things nothing else does.

Recurring versus one-off, which distinguishes subscriptions from purchases.

Cost centre and cardholder, which gives you a candidate owner.

The descriptor problem

Merchant descriptors on card statements rarely match application names.

A vendor may appear under several descriptors, including a payment processor's name rather than their own.

Descriptors are truncated, abbreviated and occasionally meaningless.

Resellers and marketplaces obscure the underlying product entirely.

Currency conversion lines appear as separate transactions.

Expect to build a mapping table by hand, descriptor to application, and to maintain it. There is no shortcut and no tool does it reliably for a mid-sized estate.

What this source finds

Departmental purchases IT never approved.

Duplicate subscriptions — the same application bought three times by three teams, at three prices.

Personal-plan pricing where a team pays per user on a consumer tier because nobody negotiated.

Applications nobody uses, still billing.

Price increases at renewal that nobody noticed.

Subscriptions belonging to people who left, still charging their card.

What it misses

Free tiers, entirely. This is the largest gap and it is where much of the data risk sits.

Annual invoices if you only look at cards.

Anything paid through a parent contract or bundled into a larger platform agreement.

Trials that have not converted yet.

Working with finance

The relationship determines whether this source is available at all.

Ask for a recurring extract, not a one-off. Monthly, by API or by report.

Offer something back: duplicate spend identified, unused seats, renewals surfaced before they auto-renew. Finance funds the programme once it sees the first saving.

Agree a coding standard. Getting software spend coded consistently makes every subsequent analysis easier and costs one conversation.

Propose the card control, which is the strongest lever available: a policy that recurring software charges require a registered application. Enforced by finance, it closes the acquisition gap in a way IT policy never will.

The reconciliation

Match descriptors to applications using your mapping table.

Flag unmatched transactions for manual review. The unmatched residue is where the discoveries are.

Compare against the SSO list to find the federation gap.

Compare against the register to find applications nobody declared.

Track the unmatched rate. A rising proportion means new applications are arriving faster than the mapping is maintained, which is itself a finding.

The annual exercise

Once a year, take twelve months of software spend and produce three lists.

Applications paid for and not in the register.

Applications in the register with no corresponding spend — free tiers, or something cancelled without the register being updated.

Applications where spend changed materially year on year, with the reason.

That exercise takes a few days and it reliably finds money. It is also the artefact that makes the case for the programme's continued existence.

The descriptor mapping table

The unglamorous artefact that makes expense data usable, and the one nobody budgets for.

Columns: descriptor as it appears, canonical application name, vendor, confidence, date mapped.

Build it from twelve months of transactions, sorted by frequency. The top fifty descriptors cover most of the spend.

Search the unfamiliar ones — the descriptor plus the amount usually identifies the vendor quickly.

Mark the genuinely unidentifiable rather than guessing, and revisit them when more transactions accumulate.

Maintain it monthly as part of the refresh, adding new descriptors as they appear.

Keep it outside any platform. It is the most laboriously assembled artefact in the programme and it should survive a change of tooling.

The card control, proposed properly

The strongest available acquisition control belongs to finance, and getting it requires making their case rather than yours.

The proposal: recurring software charges require a registered application, enforced at expense approval.

Their benefit: predictable software spend, no surprise renewals, duplicate purchases caught before payment, and a defensible answer at audit.

Their objection: it creates work for their team.

The answer: the registration is a five-field form handled by IT, and finance only checks that a reference exists.

Start with a threshold, so small charges pass and material ones do not, which makes the pilot easy to accept.

Report the first duplicate it catches, which is what converts a pilot into a standing control.