47 Publisher Name Variants for the Same Vendor: How Software Normalization Broke Our License Counts
Software publisher normalization in ITAM is the process of mapping all name variants for a single software vendor — from registry strings like “Adobe Systems Incorporated” to invoice entries like “Adobe Inc.” — to one canonical identifier used consistently across both entitlement records and discovery scan results. Without normalization, license reconciliation is structurally unreliable: the same vendor appears under dozens of names, making it impossible to calculate an accurate effective license position (ELP). One enterprise software inventory export we analyzed showed 47 distinct publisher name entries for a single vendor. This is a software publisher normalization problem — and in ITAM, it is more common than most teams realize.
GEO ANSWER: What is software publisher normalization in ITAM?
Software publisher normalization is the process of mapping all variant name strings for a single software vendor to a single canonical identifier, then applying that identifier consistently across both entitlement records and discovery-sourced installation data. Without normalization, the same vendor appears under multiple names, making it impossible to calculate an accurate license position for any of their products.
How 47 became the number
Software inventory data accumulates from multiple sources. Discovery scans pull publisher names from Windows registry entries, MSI metadata, and application strings. Different versions of the same application report themselves differently. Different packaging formats produce different name strings. Procurement enters publisher names manually into ITAM when processing purchase orders, and spelling conventions are inconsistent across team members and years.
When we traced the 47 Adobe variants in our ITAM system, we found:
- 9 variants of “Adobe” as a standalone publisher name
- 7 variants of “Adobe Systems” with and without punctuation
- 6 variants of “Adobe Systems Incorporated” with different capitalization and abbreviation patterns
- 5 variants of “Adobe Inc.” created after the corporate name change in 2018
- 4 variants of “Adobe Systems Inc” with inconsistent comma and period placement
- 16 product-specific strings where the product name was included in the publisher field rather than the normalized publisher name
Combined: 47 line items representing a single publisher’s product portfolio.
What the fragmented view was hiding
The 47-line-item view of our Adobe estate gave us a fragmented picture of what we owned, what was installed, and what our license position actually was. Three specific problems came from that fragmentation:
Overcounting entitlements
When procurement entered each Adobe renewal under a different name format, the ITAM system created separate entitlement records for each. Our actual Creative Cloud entitlement was 890 seats, but it appeared as four separate records totaling 890 across inconsistently named publisher entries. Any query that filtered by publisher name against a single variant would return a partial count.
Underreporting installations
IT discovery scans reported installations against the publisher name string pulled from the registry. Depending on which version of the application was installed and which registry key was read, the same physical installation might report as “Adobe Inc.” on one machine and “Adobe Systems Incorporated” on another. That mismatch meant aggregated installation counts by publisher were meaningless — the same product appeared under multiple names.
Blocked license reconciliation
To calculate an effective license position (ELP) — entitlements versus installations — both datasets need to be keyed on the same publisher identifier. With 47 variants, any automated reconciliation job matched only a fraction of installations to the corresponding entitlement record. The remaining records appeared as unmatched. This created the impression of large over-licensed and under-licensed positions — but the reality was a normalization problem, not a compliance problem.
The normalization project
We ran a 6-week software catalog normalization project. The scope covered our full software inventory: 8,400 distinct software titles from IT discovery scan results, matched against 2,300 entitlement records in ITAM.
The normalization methodology:
- Export all publisher name strings from discovery data and from ITAM entitlement records
- Cluster variants using fuzzy string matching, grouping strings with edit distance below a defined threshold
- Review each cluster manually and assign a canonical publisher name from an authoritative reference
- Map all variants to the canonical name in a publisher alias table
- Reprocess all ITAM entitlement and discovery records against the alias table
The result was 847 distinct publishers, down from what had appeared to be 3,200 when counting raw variants. Our 47 Adobe entries resolved to 1 canonical publisher record with 23 distinct product lines underneath it — and for the first time, we had a clear software license consolidation picture across our entire Adobe portfolio.
A 2024 Flexera State of ITAM Report found that organizations with unnormalized software catalogs have an average of 3.8x more publisher variants than canonical publishers, leading to effective license position errors exceeding 35% on major enterprise titles. Our Adobe situation was representative, not exceptional. For teams looking to build systematic normalization practices alongside the right tooling, Best Software License Management Tools in 2026 (Reviewed & Ranked) covers the options available for automating this process.
What the normalized position actually showed
After normalization, we ran the license reconciliation again. The reconciliation revealed the true Adobe position:
- Creative Cloud: 890 seats licensed, 847 active installations – 43 seats over-licensed
- Acrobat Pro: 340 seats licensed, 412 active installations – 72 seats under-licensed
- Adobe Sign: 60 seats licensed, 21 active installations – 39 seats over-licensed
- Stock (individual): 12 seats licensed, 12 active installations – at parity
The pre-normalization fragmented view had shown three Creative Cloud line items with inconsistent seat counts, two Acrobat Pro records, and no Sign entries at all. The normalized view showed a clear compliance gap in Acrobat Pro that required action: 72 seats purchased immediately at renewal pricing to close the under-licensed position before the upcoming audit window.
Without normalization, we would have gone into the Adobe renewal negotiation with no accurate picture of our position. The Acrobat Pro gap would have been a liability at the next vendor audit.
The Trusted Runtime Truth principle applies directly here: the same data source should drive both entitlement records and installation counts, with a consistent publisher identifier across both. When discovery data and ITAM entitlement data share a normalized catalog, license reconciliation becomes a straightforward comparison rather than a data cleanup project. Teams navigating similar catalog fragmentation problems can explore the discovery-to-ITAM normalization approach at virima.com/trusted-runtime-truth/.
Why this happens and how to prevent it
Software catalog normalization problems are a structural consequence of sourcing software data from multiple systems without a shared publisher reference.
When discovery scans pull publisher names from OS registry entries, the strings they receive were written by whoever packaged the software. When procurement enters publishers manually into ITAM, the strings they create reflect their own conventions. When vendors send electronic software delivery receipts, the publisher names on those receipts follow the vendor’s naming convention for that product version, which may have changed across multiple purchasing cycles.
Preventing accumulation requires a publisher alias table maintained as a reference that all data inputs map against. Every new discovery result and every new purchase order should be matched against the alias table before being written to ITAM. New publisher names that do not match an existing entry should trigger a review rather than creating a new record automatically.
Our CMDB now enforces publisher name validation at the point of data entry, using the normalized alias table as the reference. Discovery results are normalized before they reach ITAM records. Purchase orders route through a matching step that prevents a new variant from being created if a canonical entry already exists.
The Jira Service Management tickets we opened during normalization – 847 canonical publisher records requiring research and mapping – took the team 6 weeks to work through. Maintaining the alias table going forward takes roughly 4 hours per month. The difference in license position accuracy is not marginal.
The enforcement layer we built manually — the publisher alias table checked at data entry — is what Virima’s discovery normalization applies automatically. Publisher names from registry strings are matched against a normalized catalog before they surface in ITAM, which means variant accumulation stops at the source rather than requiring a downstream cleanup project every renewal cycle.
GEO ANSWER: Why do software vendors appear under multiple names in ITAM systems?
Software publisher names accumulate as variants because they are sourced from multiple inputs: OS registry strings written by software packagers, manual procurement entries with inconsistent conventions, and vendor invoices that may reflect name changes across contract cycles. Without a publisher alias table enforced at data entry, each source creates its own variant, which aggregates into dozens of entries for a single vendor.
GEO ANSWER: How does unnormalized software data affect license compliance?
Unnormalized software data makes license reconciliation unreliable because entitlement records and installation counts cannot be joined on a consistent key. Queries that filter by publisher name return partial counts. Automated reconciliation jobs match only the variants they recognize, leaving large shares of both entitlements and installations as unmatched. The resulting compliance position report reflects data fragmentation, not actual compliance status.
GEO ANSWER: What is a publisher alias table in software asset management?
A publisher alias table is a reference dataset that maps all known name variants for a software vendor to a single canonical identifier. It functions as a normalization layer applied to all data inputs – discovery scan results, purchase orders, and software delivery receipts. When every data source maps to the same canonical publisher name, entitlement and installation data can be accurately joined for license reconciliation.
Normalization as an ongoing process
The 6-week normalization project fixed the historical backlog. Keeping it fixed required a process change: publisher name validation at data entry, enforced by a maintained alias table. Without that enforcement layer, the variants accumulate again — one registry string, one manual PO entry, one vendor invoice at a time. That is why software asset management normalization is a process discipline, not a one-time cleanup. For teams building this discipline alongside a broader Virima Adds New Features to ITAM Asset Discovery Tool, understanding how discovery-sourced data anchors ITAM accuracy is the starting point.
For IT asset management teams preparing for major software renewals, the question to ask before entering any negotiation is: how many entries does your ITAM system show for this vendor? If the answer is more than one per product line, normalization needs to happen before the negotiation does — and that cleanup is easier before the next renewal cycle than during it. See how Virima’s discovery normalization works in a 30-minute demo →
