Chargeback operating model
The core design decision was to turn one centralized Zoom bill into a business-unit ownership model that leadership could actually use for accountability.
Case Study
Structuring Zoom billing and chargeback reporting for 100 business units.
At Fullsteam, I identified a billing visibility gap in the growing Zoom environment and built the reporting system behind it. Using n8n, Zoom APIs, Google Sheets, SharePoint, and Power BI, I turned fragmented Zoom billing and usage data into a business-unit-level chargeback model that made licenses, phone usage, Contact Center usage, and number ownership much easier to understand.
Company
Fullsteam
Role
Business Systems Analyst
Tools
Zoom APIs, n8n, Google Sheets, Python, SharePoint, Power BI
Business Problem
The problem was not just billing. It was ownership visibility across a growing Zoom footprint.
As Zoom expanded across Fullsteam, costs were being absorbed centrally even though usage was being created by many different business units, products, and account structures.
Fullsteam was absorbing Zoom costs centrally even though licenses, phone usage, phone numbers, and Contact Center activity were being generated by many different business units.
Zoom's native billing and reporting did not provide a clean executive-level view of ownership across parent-account users, sub-account users, phone numbers, and usage records.
The environment needed a reporting layer that could turn fragmented Zoom product data into business-unit-level chargeback, governance, and cost visibility.
Approach
I built the data model behind the chargeback before building the executive report.
That meant collecting data from across Zoom's fragmented product areas, reconciling identities and ownership, then layering pricing and reporting logic on top of the cleaned structure.
Identified the billing gap proactively and treated it as both a financial-operations problem and a systems-data problem.
Built a daily n8n workflow that pulled users, groups, licenses, phone users, Contact Center users, phone numbers, queues, ported numbers, and usage charges from both the parent account and sub-accounts.
Stitched related Zoom records together so a business unit could be tied to a standard Zoom user, Zoom Phone user, Zoom Contact Center user, phone number, and charge record.
Used preset license pricing and grouped usage by number and reporting period to turn Zoom activity into business-unit chargeback logic.
Stored the cleaned data in Google Sheets, moved it into SharePoint, and surfaced it in Power BI for executive and business-unit reporting.
System Design
The reporting only worked because the user, number, license, and usage model underneath it was stitched together correctly.
The strongest part of the build was not one report. It was the way account structure, user mapping, attribution logic, and reporting flow were all connected into one system.
Cross-product user mapping
The system had to reconcile standard Zoom users, Zoom Phone users, and Zoom Contact Center users so one person's license and usage footprint could be understood as one reporting entity.
Business-unit attribution
Phone numbers, queues, usage records, and sub-account placement were all used to connect cost back to the correct business-unit context instead of leaving ownership ambiguous.
Reporting pipeline
Google Sheets acted as the structured repository, SharePoint moved the dataset into the Microsoft stack, and Power BI became the polished reporting layer for leadership.
Technical Details
The technical work was in the stitching, normalization, and attribution.
Zoom had the source data, but not the reporting layer Fullsteam needed. The implementation required collecting from multiple APIs, reconciling identities across product areas, and structuring the result for downstream finance and executive use.
Parent and sub-account collection
The workflow collected data from both the main Fullsteam Zoom account and business-unit sub-accounts, then merged those records into one unified reporting model so the chargeback system covered the full environment.
User and license inventory
The user table included user ID, email, created date, last login, group or sub-account, employee metadata, license details, phone access, phone site, calling plans, Contact Center package, role, and team information.
Usage-charge normalization
Phone calls, SMS, MMS, and fax charges were pulled across selected date ranges, normalized into structured fields, and grouped by billing number and reporting period so usage could be rolled up cleanly.
Phone-number attribution logic
Usage charges were tied back to phone numbers first, then connected to users, groups, queues, and sub-accounts so each charge could be assigned to the right business unit.
Ported number and queue inventory
The system also tracked ported-number orders, phone-number inventory, phone queues, Contact Center queues, and queue members so the reporting layer reflected operational structure, not just cost totals.
Historical backfill and sync logic
I used the same architecture for daily runs and for rebuilding historical visibility across 2025 and late 2024, with update and sync-hash logic in Google Sheets to avoid blind duplication.
Outcomes
The result was a governable Zoom cost model at portfolio scale.
The measurable impact mattered, but the larger value was giving Fullsteam a real operating model for understanding and allocating Zoom cost across the portfolio.
Created visibility into approximately $480,000 in annual Zoom-related cost that could be redirected back to the responsible business units.
Turned a centralized telephony expense into a structured business-unit reporting and chargeback model.
Gave Fullsteam clearer license visibility, usage attribution, number ownership, and Contact Center cost context across the Zoom footprint.
Built an executive reporting path that supported daily, monthly, quarterly, annual, historical, and ad hoc analysis instead of one-off billing interpretation.
Key takeaway
This was not just a billing report. It was the missing reporting and attribution layer behind a shared Zoom platform.
Lessons Learned
Platform scale changes what useful reporting actually requires.
At this size, the hardest part is not visualizing spend. It is building a clean ownership model across fragmented product data so the reporting can be trusted.
Standardizing a platform also means designing the ownership and billing model behind it.
Chargeback reporting becomes trustworthy only when attribution is tied to real system structure like users, numbers, queues, and sub-accounts.
Automation is most useful when it connects fragmented APIs into one reporting layer the business can actually act on.