VMware to ServiceNow Chargeback / Showback Integration¶

Scope¶

This pattern covers the end-to-end integration that takes VMware private-cloud cost and consumption data, lands it in ServiceNow as the authoritative system of record for IT financials and service ownership, and produces showback dashboards or full chargeback with journal entries to the customer's ERP. It is fundamentally a multi-product integration: VMware/Broadcom for the cost data source (Aria Cost / CloudHealth, VCF Operations consumption metrics, vCenter tags), ServiceNow for the CMDB and financial allocation layer (Discovery, IntegrationHub VMware spoke, Financial Management / Cloud Cost Management / APM), and the customer's ERP for the eventual journal entries (SAP, Oracle Financials, Workday). The cloud-agnostic showback-vs-chargeback fundamentals (tagging gates, hybrid models, organizational maturity) live in general/finops.md and general/cost.md; this file does not repeat them. The VMware/ServiceNow-specific question -- how the data physically flows from vCenter and CloudHealth into ServiceNow CMDB and then into a chargeback engine, and what the post-Broadcom equivalent of the legacy vRealize Business / ITBM connector actually is -- is the value this file adds.

Overview¶

The integration has four layers and any design has to make a decision at each one:

Cost data source. Where does the dollar amount come from? Options include Aria Cost / CloudHealth (now Broadcom CloudHealth) for financial cost, VCF Operations (formerly Aria Operations) for consumption metrics that drive allocation, vCenter tags and categories for the metadata that ties cost to a business unit, and third-party FinOps platforms (Apptio Cloudability, Nicus, Vantage) for organizations that do not want a Broadcom dependency.
CMDB and metadata. ServiceNow has to know which VM belongs to which business unit, application, and cost center. The mechanisms are ServiceNow Discovery against vCenter, the IntegrationHub VMware spoke, Service Mapping for application-to-VM relationships, and tag synchronization from vCenter categories into CMDB CI custom attributes.
Allocation engine. Once cost and metadata are landed, something has to allocate cost across business units. Options inside ServiceNow include the Financial Management (formerly ITBM Financial Management) module, the newer Cloud Cost Management / Cloud Insights capability, and APM (Application Portfolio Management) for application-level cost. Outside ServiceNow, the engine can be Apptio, Nicus, or a custom ServiceNow App Engine application.
Output. Either showback dashboards inside ServiceNow Performance Analytics, full chargeback with journal entries written to the customer's ERP, or invoices generated for managed-service customers. Each output mode has different precision, reconciliation, and dispute-handling requirements.

The legacy reference design used vRealize Business for Cloud as the cost source and a dedicated ITBM connector to push it into ServiceNow. Both have been disrupted: vRealize Business for Cloud was discontinued years before the Broadcom acquisition, ITBM was renamed and re-bundled, and Aria Cost / CloudHealth has itself moved under Broadcom and is now branded as Broadcom CloudHealth. Many production integrations therefore run on a mixture of file-based imports, custom Scripted REST APIs, and partially-broken legacy connectors. Honest treatment of the current-day equivalent is part of the design.

Checklist¶

Cost data source¶

[Critical] What is the authoritative source for the financial cost of a VMware private-cloud VM, and is its current product name verified with the vendor account team before the design is finalized? (Aria Cost has been renamed and re-bundled multiple times -- it originated as CloudHealth, was rebranded as VMware Aria Cost powered by CloudHealth, and is now positioned as Broadcom CloudHealth under the Broadcom FinOps line; the legacy vRealize Business for Cloud product was discontinued and its private-cloud cost-modeling capability was partially absorbed but not fully replaced; verify entitlement and feature scope against a current Broadcom-authorized partner rather than older documentation)
[Critical] Is consumption data (vCPU-hours, GB-RAM-hours, IOPS, storage-GB-months) collected from VCF Operations (formerly Aria Operations) at sufficient granularity for the chosen allocation methodology? (Per-VM flat-rate allocation needs only an inventory snapshot; per-vCPU-hour or per-GB-RAM-hour consumption-based allocation needs hourly or 5-minute samples; under-collection forces a fallback to flat-rate that hides the heaviest consumers and undermines the entire point of chargeback)
[Recommended] If Broadcom CloudHealth / Aria Cost is not in use, what is the substitute, and does it have the same private-cloud awareness? (Third-party FinOps platforms like Apptio Cloudability, Nicus, and Vantage have stronger public-cloud depth than VMware private-cloud depth; native ServiceNow Cloud Cost Management ingests public-cloud billing but historically has weaker first-party VMware coverage than CloudHealth; a roll-your-own pipeline from vCenter and the storage array into a custom rate card may be the most accurate option but requires ongoing engineering)
[Recommended] Are shared-infrastructure costs (NSX licensing, VCF management domain hosts, vSAN witness, backup infrastructure, monitoring stack, network fabric) modeled separately from per-VM costs, and is the allocation method for them defined? (Treating only the workload-domain ESXi cost as "the VMware cost" understates the true cost by 20-40 percent; shared costs are typically allocated proportionally by VM count, by vCPU consumption, or as a flat per-VM overhead burden -- the choice materially affects which BUs subsidize which)

CMDB and metadata¶

[Critical] Is ServiceNow Discovery configured against vCenter with the appropriate MID Server placement, credentials, and identification and reconciliation engine (IRE) rules so that vCenter VMs become first-class CIs without duplicates? (One MID Server per network segment with vCenter read-only service account; IRE rules keyed on vCenter UUID rather than VM name, since names change and reused names cause CI duplication; without correct IRE, the same VM appears as multiple CIs over time and cost allocation becomes incoherent)
[Critical] Is the IntegrationHub VMware spoke (or the historical VMware vCenter spoke) used for event-driven CMDB updates instead of relying solely on scheduled Discovery? (Scheduled Discovery has a lag measured in hours; event-driven updates via the IntegrationHub spoke or vCenter webhook integration capture VM creation, deletion, and migration in near real time, which is required for accurate end-of-period accounting when VMs are created or decommissioned mid-cycle)
[Critical] Is the authoritative owner of cost-allocation metadata explicitly chosen -- ServiceNow CMDB CI owner, vCenter folder owner, vCenter tag, Aria Automation deployment owner, or Aria/CloudHealth perspective? (Each of these can drift independently; choosing CMDB as authoritative means vCenter tags are reconciliation inputs but not the source of truth, and a discrepancy means the CMDB value wins; choosing vCenter tags as authoritative means CMDB is downstream and the IRE pulls tag values into CI fields; this decision must be made up-front because reversing it later means rewriting allocation logic)
[Recommended] Are vCenter tag categories synchronized into ServiceNow CMDB CI custom attributes in a way that survives upgrades and rebrands? (Categories like cost-center, application, environment, business-unit, data-classification are the linkage between a VM and its allocation target; the synchronization can be Discovery-driven, IntegrationHub-spoke-driven, or implemented as a scheduled Scripted REST job -- verify which mechanism the current spoke version actually supports, since this has changed across vRealize, Aria, and VCF generations)
[Recommended] Is a reconciliation report produced regularly that identifies CIs in CMDB without a corresponding vCenter VM and vCenter VMs without a corresponding CI? (Stale CIs continue to accrue allocated cost against a business unit that no longer owns the workload; VMs missing from CMDB are operating untagged and untracked, often in dev or shadow-IT contexts; both undermine chargeback credibility and erode trust in the dataset)
[Recommended] Is tag governance enforced upstream so that VMs cannot be provisioned without the mandatory cost-allocation metadata? (Aria Automation / VCF Automation blueprints can require tags at provisioning time; vCenter does not natively enforce required tags but can be wrapped by Aria Automation or by a ServiceNow Service Catalog item; without enforcement, tagging coverage drifts below the 90-95 percent gate that general/finops.md identifies as the threshold for credible chargeback)

Allocation methodology¶

[Critical] Which allocation methodology is chosen -- per-VM flat rate, per-vCPU-hour and per-GB-RAM-hour consumption-based, per-cluster-share, or weighted by service tier -- and does the choice match the granularity of available consumption data? (Per-VM flat-rate is the simplest and the least accurate, hiding utilization differences between a near-idle VM and a saturated one; per-vCPU-hour / per-GB-RAM-hour is the most defensible and the most data-hungry; per-cluster-share allocates the cluster's total cost across only the VMs that ran on it, which handles dedicated-cluster BUs cleanly but requires per-cluster cost rollup; weighted-by-tier allows Platinum / Gold / Silver service-level pricing on top of any of the above)
[Recommended] Is the rate card published, version-controlled, and reviewed on a defined cadence with finance? (A rate card that changes silently destroys trust; a rate card frozen for years stops reflecting actual costs as hardware refreshes and licensing changes; annual review at budget time with quarterly minor adjustments is a typical cadence)
[Recommended] Are mid-cycle changes (VM created, decommissioned, resized, migrated between clusters) handled with proration, or are they billed on snapshot-at-end-of-month basis? (Proration is more accurate but requires hourly inventory and is harder to dispute; snapshot is simpler but penalizes BUs that decommissioned late in the month and rewards BUs that created late in the month -- the choice depends on cycle length and dispute tolerance)

Output and ERP integration¶

[Critical] Is the output mode chosen -- showback dashboards only, internal chargeback against BU budgets inside ServiceNow, or full chargeback with journal entries posted to the ERP (SAP, Oracle Financials, Workday) -- and does the chosen mode match the organization's tagging coverage and finance-system maturity? (Showback is appropriate below the 90 percent tagging coverage gate from general/finops.md; internal chargeback against ServiceNow-tracked BU budgets requires 90-95 percent coverage; full ERP journal-entry chargeback requires both the coverage and an existing ServiceNow-to-ERP integration -- typically via IntegrationHub spokes for SAP / Oracle / Workday, or via file-based exports if no spoke is in use)
[Recommended] For full chargeback, is the monthly close cadence defined with lock dates, dispute window, and re-open process? (Typical: cost data frozen at month-end + 3 business days, dispute window of 10-15 business days, ERP journal entries posted at month-end + 20 business days; without a defined cadence, finance cannot close the books and chargeback gets reverted to showback under pressure)
[Optional] For multi-entity or multi-currency organizations, is transfer pricing and intercompany allocation modeled correctly? (Cost incurred by entity A on behalf of entity B must be transferred at an agreed price with the right currency conversion at the right date; this is rarely handled inside ServiceNow Financial Management and typically requires the ERP's intercompany module -- verify the integration produces ERP-compatible records, not just an internal allocation)

Operations¶

[Recommended] Is tagging compliance reporting published to BU owners on a cadence that gives them time to fix gaps before the close? (Weekly reports flagging untagged VMs, with the BU owner identified through CMDB ownership, drive coverage up; monthly reports timed two weeks before close give owners a remediation window; without a feedback loop, tagging coverage degrades over time as new VMs are created without metadata)
[Recommended] Is the integration end-to-end monitored, with alerts for ingestion gaps, stale data, and reconciliation drift? (A silent failure in the CloudHealth-to-ServiceNow ingestion can produce a clean-looking dashboard with three-week-old data; monitor freshness of the last successful cost-data import, the last successful Discovery sync, and the count of CIs without recent updates; route alerts to the platform team rather than the finance team)

Why This Matters¶

Chargeback is the conversation that exposes whether an organization actually knows what its VMware estate costs. Most VMware-heavy organizations run ServiceNow as the system of record for IT financials and service ownership, so the integration question is asked at every mature engagement: "we have vCenter, we have ServiceNow, how do we charge departments for the VMs they own?" Without a clear pattern, the answer defaults to either a manually reconciled spreadsheet maintained by a single analyst (fragile, opaque, and unauditable) or to buying every Aria and ServiceNow module the vendors suggest (over-licensed, under-implemented, and frequently still ending in the spreadsheet). Both outcomes are common, and both are visible in any audit of the actual production state.

The integration is high-stakes because it ties directly to the customer's general ledger. Once chargeback is producing ERP journal entries, an error in tagging, allocation, or rate-card application becomes a financial restatement, not just a reporting issue. This is also why the integration is frequently bungled: the data-engineering depth required to land CloudHealth cost data, vCenter inventory, VCF Operations consumption metrics, and CMDB metadata in a consistent monthly close is genuinely high, and most implementation teams underestimate it. The first six months of production chargeback are typically dominated by reconciliation disputes that surface every gap in the underlying tagging and CMDB hygiene.

The integration is in flux post-Broadcom and that flux is the strongest argument for treating it as a pattern rather than as a checklist for any single product. vRealize Business for Cloud, which was the original VMware-side cost product with a native ServiceNow ITBM connector, was discontinued years ago and its private-cloud cost-modeling capability was only partially replaced. CloudHealth was VMware's, then Aria's, and is now Broadcom's, with the branding and SKU landing differently each renewal cycle. ServiceNow ITBM was rebranded across multiple releases and its financial-management capability has been re-bundled with Cloud Cost Management and APM in ways that vary by license level. As a result, an organization that built this integration five years ago needs to redesign it now, and an organization building it for the first time cannot rely on a single canonical reference. The honest design starts by verifying with the vendor account teams which products are currently entitled and which connectors are currently supported, then chooses a deliberate path through the current product names.

Finally, the chargeback pattern is the operational test of the broader FinOps maturity described in general/finops.md. The 90-95 percent tagging coverage gate, the showback-before-chargeback progression, and the shared-cost allocation methodology are all relevant; this pattern is where they get applied against a specific stack. An organization that has tried and failed at VMware chargeback has almost always failed at one of the upstream gates -- tagging, CMDB accuracy, or rate-card governance -- and the failure shows up as a chargeback that nobody trusts.

Common Mistakes¶

Treating the chargeback design as a tooling question instead of a metadata question. The largest predictor of success is tagging coverage and CMDB accuracy, not which cost-allocation product is chosen. Buying CloudHealth, ServiceNow Cloud Cost Management, and Apptio simultaneously does not fix 60 percent tag coverage.
Assuming vRealize Business for Cloud's ITBM connector is still a valid reference architecture. It is not. The legacy connector and the legacy product line were discontinued; designs that copy it without replacement are starting from a non-existent base.
Allocating only the workload-domain ESXi cost. The VCF management domain, NSX, vSAN witness, backup infrastructure, networking fabric, and monitoring stack are 20-40 percent of the true cost and must be allocated by a defined method, not silently absorbed by central IT.
Mixing authoritative ownership across vCenter, CMDB, and Aria/CloudHealth without choosing one. When three systems disagree about which BU owns a VM, the allocation engine picks whichever value it reads first, and the BU that should be charged is not.
Jumping to full ERP chargeback before tagging coverage clears the 90-95 percent gate from general/finops.md. The result is chargeback that the BUs immediately dispute, which forces a revert to showback under pressure and discredits the program.
Building the pipeline as a one-time integration project rather than as a monitored ongoing data flow. Silent failures in the CloudHealth-to-ServiceNow ingestion produce a clean-looking dashboard with stale data, and the failure is typically discovered only at month-end close.

Key Patterns¶

Showback-first, chargeback-second. Land cost data into ServiceNow as visibility-only Performance Analytics dashboards for two to four quarters, fix the tagging and CMDB issues that surface, then transition to chargeback. Trying to skip the showback phase predictably fails at the first close.
CMDB as authoritative, vCenter and Aria/CloudHealth as inputs. ServiceNow CMDB is the system of record for ownership; vCenter tags and Aria/CloudHealth perspectives reconcile into CI custom attributes. Reverse arrangements (vCenter authoritative) are common in environments that adopted ServiceNow late, but they make integration with ERP harder because the ERP integration is anchored on ServiceNow records.
IntegrationHub spoke plus Discovery, not either alone. Discovery for the full CI inventory, IntegrationHub spoke for event-driven updates on VM lifecycle changes. Discovery alone has too much lag for accurate end-of-period accounting; spoke alone has gaps in initial inventory and reconciliation.
Layered allocation: workload cost per-consumption, shared cost proportionally, tier multiplier on top. Per-vCPU-hour and per-GB-RAM-hour for the workload portion, proportional allocation of NSX / management / fabric / monitoring overhead, then a Platinum / Gold / Silver multiplier for service-tier pricing. This layered model survives audit better than a single flat rate because each component is independently defensible.
Honest treatment of the legacy ITBM connector gap. Document explicitly that the post-Broadcom equivalent of the vRealize Business / ITBM connector is in flux and that the current implementation uses whichever combination of IntegrationHub spoke, Scripted REST, and file-based import the vendor support teams confirm. This is a more durable design than pretending a clean canonical path exists.

Common Decisions (ADR Triggers)¶

Cost data source: Broadcom CloudHealth / Aria Cost vs third-party FinOps (Apptio Cloudability, Nicus, Vantage) vs native ServiceNow Cloud Cost Management vs roll-your-own from vCenter + storage rate card. CloudHealth has the strongest VMware private-cloud awareness but a Broadcom dependency that is in flux; third-party FinOps platforms have stronger public-cloud depth and vendor neutrality; native ServiceNow Cloud Cost Management reduces tool sprawl but historically has weaker VMware private-cloud depth; roll-your-own is the most accurate and the highest ongoing engineering burden.
Allocation engine: ServiceNow Financial Management (formerly ITBM) vs ServiceNow Cloud Cost Management / Cloud Insights vs Apptio vs Nicus vs custom App Engine. ServiceNow Financial Management is the historical default but has been re-bundled across releases; Cloud Cost Management is the newer ServiceNow positioning; Apptio and Nicus are best-of-breed third-party engines often selected when ServiceNow's financial-management depth is insufficient; custom App Engine applications are common when none of the above fit but increase maintenance burden.
Showback vs full chargeback vs hybrid with budget guardrails. Showback for organizations below the 90 percent tagging gate; full chargeback with ERP journal entries for organizations above the gate with mature finance-system integration; hybrid (showback dashboards plus BU budget alerts) for the in-between case, which is also the most common starting state.
Authoritative ownership: ServiceNow CMDB vs vCenter tags vs Aria Automation deployment owner vs CloudHealth perspective. Once chosen, this decision is expensive to reverse because the allocation logic and reconciliation rules are built on top of it. CMDB-authoritative is the most common for organizations whose ERP integration is already anchored on ServiceNow.
Allocation methodology: per-VM flat rate vs per-vCPU-hour and per-GB-RAM-hour vs per-cluster-share vs tiered Platinum/Gold/Silver. Flat rate is the simplest and the least defensible against utilization-aware BUs; consumption-based is the most defensible and the most data-hungry; per-cluster-share is the cleanest for dedicated-cluster BUs; tiered pricing layers on top of any of the above.
CMDB ingestion mechanism: IntegrationHub VMware spoke vs Discovery alone vs file-based imports vs custom Scripted REST. The post-Broadcom IntegrationHub VMware spoke is the documented path but should be verified for current version coverage against the deployed VCF / Aria / vCenter versions; Discovery alone is sufficient only for showback; file-based imports and custom Scripted REST are the fallbacks when spoke support lags the deployed VMware version.
Re-platforming from discontinued vRealize Business / legacy ITBM connector vs buying current-generation tooling. Organizations on the legacy path have to choose between a Broadcom CloudHealth + current ServiceNow Cloud Cost Management stack, a third-party FinOps stack (Apptio, Nicus), or a roll-your-own pipeline; pretending the legacy connector still exists as a supported integration is not an option.
ERP integration mechanism: ServiceNow IntegrationHub ERP spoke (SAP / Oracle / Workday) vs file-based exports vs middleware (MuleSoft, Boomi, Informatica). Native IntegrationHub spokes are the cleanest path when entitled; file-based exports work for monthly cadence but break for any sub-monthly process; middleware is common in organizations that already operate an enterprise integration platform.

Reference Architectures and Links¶

Broadcom CloudHealth product page -- current product positioning of the former VMware Aria Cost / CloudHealth, including supported integrations
Broadcom TechDocs portal -- post-acquisition documentation home for VCF, Aria, and CloudHealth; the former docs.vmware.com URLs now redirect here
ServiceNow product documentation -- IntegrationHub, Financial Management, Cloud Cost Management, Discovery, and Service Mapping; verify product naming against the customer's current release (Yokohama, Zurich, etc.)
ServiceNow Store -- IntegrationHub VMware and Broadcom spokes; verify current spoke versions and supported source-system versions before designing around them
FinOps Foundation Framework -- vendor-neutral framework for the Inform / Optimize / Operate phases that underlie any chargeback program