Reconciling Discovery Sources

Discovery gives you four lists. Turning them into one register is the part nobody budgets for.

Why the join is hard

Names differ everywhere. The identity provider has a configuration label, the card statement has a merchant descriptor, the OAuth grant has a developer-supplied application name, and the vendor's own branding may differ from all three.

Vendors rename, merge and get acquired. A subscription bought under one name renews under another.

Products bundle. A platform sold as one product appears as several applications in an SSO list.

Resellers obscure the vendor in expense data entirely.

Free and paid tiers of the same product look like different applications.

Building the mapping

One canonical application record, with a name you chose.

Aliases attached to it: every SSO label, every merchant descriptor, every OAuth application name, every colloquial name people use.

Match by domain where possible. The vendor's domain is more stable than any name and appears in SSO metadata, OAuth grants and frequently in expense descriptors.

Match by admin contact, which occasionally resolves ambiguity.

Everything else by hand, reviewed by someone who knows the estate.

Expect a few days for a mid-sized estate, and expect the mapping to need maintenance monthly.

The unmatched residue

The most valuable output of the exercise.

Transactions matching no known application are either new purchases or descriptors you have not mapped. Both are worth resolving.

SSO applications with no spend are free tiers, bundled products, or something cancelled without deprovisioning.

OAuth grants matching nothing are the genuinely unknown applications, and they are the ones to look at first.

Track the unmatched rate per source, monthly. A rising rate means either acquisition is accelerating or the mapping has stopped being maintained, and both need a response.

Deduplication

Separate from matching, and it produces the consolidation findings.

The same product bought twice by two teams, at two prices, on two contracts. Extremely common and it is money on the table.

Overlapping products in the same category. Three project trackers is a decision nobody made.

A product bought centrally and also departmentally, where the departmental buyer did not know the central licence existed.

Report these by category rather than by application. "We pay for four file-sharing services" lands better than four separate line items.

Keeping the register as the source of truth

One record per application, with aliases, and every source maps into it rather than beside it.

Never let a discovery tool's list become the register. Tools change, and a register that lives inside one is lost when you change vendors.

Store the mapping outside any platform, so it survives replacement.

Version it, so a change in counts can be attributed to a mapping change rather than to reality.

What good looks like after six months

Unmatched rate below a few percent on each source.

A mapping table with aliases that someone maintains.

Monthly refresh producing a diff rather than a full re-analysis.

New applications appearing as alerts, not discovered at the annual review.

The register answering questions in minutes rather than triggering a project.

When two records are actually one

Deduplication rules that resolve most cases without judgement calls.

Same vendor domain, different product names: usually one vendor relationship, possibly several products. Keep separate records, link them to a shared vendor record.

Same product, different tiers or regions: one record, with the variants noted.

Free tier and paid tier of the same product: one record. The free tier is frequently a different team using the same tool, and merging them reveals a consolidation opportunity.

Product renamed after acquisition: one record, with the old name as an alias and the change dated.

Two contracts for the same product bought by two teams: one application record, two contract records. This is the case that produces the largest savings and the one most often left as two separate entries.

Record the merge and the reasoning, because someone will later ask why the count fell.

Keeping the mapping portable

The alias table is the most laboriously assembled artefact in the programme and the easiest to lose.

Store it outside any vendor platform, in a format you control.

Version it, so a change in application counts can be attributed to a mapping change rather than to the estate.

Document the rules, not just the results, so a successor can extend it consistently.

Export it monthly alongside the register.

Test the export by rebuilding from it once, which is the only way to know it is complete.

A platform migration with the mapping intact is a week of work. Without it, it is the original reconciliation exercise repeated from nothing.