Mapping Technology Costs to Technology Resource Towers
A Multi-Pass Approach to Extending Your TBM Model
Mapping technology costs to Resource Towers is a foundational step in building a meaningful TBM model. It allows organizations to understand not just what they’re spending money on—but where and how that money supports the technology stack.
Where Cost Pools categorize expenses by type (e.g., software, labor), Towers categorize expenses by function (e.g., Application, Platform, End User). This added dimension enables service-level insights and supports nearly all advanced TBM use cases, including optimization, planning, chargeback, and transparency.
Tool-Agnostic Guidance
The tower mapping approaches on this page are designed to be platform-agnostic. They outline general processes that can be adapted to most commercial TBM tools, and are equally suitable for implementation in spreadsheets or basic databases.
Whether you’re using enterprise software or building your model manually, these mapping strategies are structured to be accessible and scalable.
Why Map to Towers?
Without tower mapping, technology costs remain siloed in general ledger categories such as cost centers, vendors, or contracts—none of which reflect the function or service the cost supports. Tower mapping translates raw financial data into a functional view of the technology organization, using a standardized, vendor-agnostic language.
By mapping costs to towers and sub-towers, you make your financial data:
- Actionable for service owners and architects
- Interoperable with cloud, agile, and sustainability analytics
- Transparent to executives and business stakeholders
Towers provide a consistent “backbone” for nearly all TBM analytics. Whether your goal is optimization, chargeback, cloud cost governance, or ESG alignment, tower mapping is the critical first step in making technology costs understandable and actionable.
Budget Mapping Note
The tower mapping methods described on this page can also be used to map budget data to Resource Towers. If your budget lines contain similar fields — such as vendor names, project codes, labor roles, or cost centers — you can follow the same step-by-step approaches.
The key consideration when working with budget data is that amounts are typically planned rather than actuals, and may be less granular or standardized. Be especially careful with allocation assumptions and mapping accuracy, and consult your finance team if budget structures differ from actuals.
What Becomes Possible After Mapping to Towers
Once your costs are mapped to towers and sub-towers, you can unlock a wide range of high-value TBM use cases and analytics:
- Tower Benchmarking: Compare your spending by tower to peers or benchmarks to identify optimization opportunities.
- Budgeting and Forecasting: Plan future investments at the tower level, ensuring capital and operational budgets reflect strategic priorities.
- Application TCO: Attribute underlying infrastructure and support costs to applications by tracing them through tower allocations.
- Cloud and Agile Insights: Separate cloud platform costs from legacy infrastructure, or distinguish agile team labor from traditional roles.
- Service Costing: Feed tower data into service-based costing models, creating a direct link from spend to service delivery.
- ESG and Sustainability Reporting: Allocate energy usage or carbon emissions by tower to support environmental reporting.
- Executive Reporting: Give business leaders a defensible, simplified view of where technology spend is going and why.
Towers turn cost data into insight. They’re essential for shifting TBM from bookkeeping to decision support.
Cost Pools vs. Towers
To fully model and communicate technology value, you need both cost pools and towers. Here’s how they differ:
Aspect | Cost Pool | Tower |
Definition | Categorizes what the expense is | Categorizes where/how the expense is used |
Example Category | Labor – Internal, Software – SaaS | Application, Compute, Network |
Source of Truth | Chart of Accounts / GL Line Items | Derived from mapping metadata and allocation logic |
Purpose | Enables cost transparency | Enables functional, service-level cost insights |
Required for TBM? | Yes – foundational | Yes – required for full TBM model and reporting |
Cost Pools classify spend type, while Towers reveal functional purpose. Both are required for complete TBM modeling.
Technology Resource Tower Mapping Approaches
There’s no one-size-fits-all method to tower mapping. Different types of expenses require different strategies, and most organizations need multiple approaches to fully populate their tower mappings. These approaches are presented in order of ease and mapping effectiveness:
- Vendors – Match known vendors to fixed towers based on services provided.
- Contracts – Use contract identifiers to assign towers, especially for bundled or managed services.
- Labor – Agile Teams – Map team-based labor based on delivery area or service supported.
- Labor – Traditional Roles – Use job title or function to assign labor to towers.
- Cost Centers – Assign towers based on organizational units when other data is lacking.
- Cloud Invoices – Highly granular data for cloud spend; often mapped via native tags or tooling.
- Projects – Map cost to towers based on the focus of an identified initiative.
- Fixed Assets – Map to towers using asset type or usage.
We’ve excluded some niche approaches (e.g., GL account-based tower mapping) in favor of methods with stronger alignment to TBM principles and better stakeholder accountability.
Quick Tip: Use the navigation on the left to explore individual mapping approaches, or read on for guidance on how to prioritize mapping approaches for your organization.
Tower Mapping Fields to Create
To properly document tower mappings, ensure your dataset includes the following required fields:
Field Name | Purpose |
Tech Resource Tower | TBM Tower receiving the cost |
Tech Resource Sub-Tower | TBM Sub-Tower (adds service-level clarity) |
Allocation Method / Source | Notes the mapping approach and/or the mapping table itself |
Allocation Percentage | Portion of the cost attributed to the Tower/Sub-Tower |
Allocation Amount | Result of multiplying original cost by Allocation Percent |
Optional fields:
Field Name | Purpose |
Tower Mapping Notes | Use this field for notes pertaining to mapping, such as multiple mapping matches, allocation decisions, etc. |
Tech Resource Domain | Used in TBM v5.0 to add another level of classification above Towers. Can be assigned by Tower. |
Sub-Tower Element | Optional field for more granularity within Sub-Tower (per taxonomy updates) |
Tower Tags / Flags | Flags or tag values relevant to FinOps, ESG, AI, or other connected data models |
Create Your Tower Mapping Plan
Before you map your first GL record:
- Familiarize yourself with TBM Tower and Sub-Tower definitions. Each sub-tower has specific criteria, especially in TBM Taxonomy v5.0.
- Understand which fields are available and interpretable, and whether you have the supporting information needed to turn those fields into mapping insights.
Step 1: Inventory Fields and Interpretability
Input: Your general ledger data, TBM Sub-Tower definitions, access to supporting source systems (e.g., contract repository, HR system, CMDB), and human stakeholders who can interpret values.
Create a table that evaluates the presence of useful data fields and whether you can interpret those fields meaningfully. This includes checking whether the values can be linked to external reference documents or clarified through stakeholder input.
Field | Exists in GL? | Interpretable? | Supporting Source | Stakeholders to Engage |
Vendor | Yes | Maybe | Procurement systems or vendor index | Procurement |
Contract ID | Yes | Maybe | Contract repository or shared drive | Legal, Procurement |
Labor Role / Title | Yes | Yes | HR or finance labor allocation tables | HR, Workforce Planning |
Team Name | Sometimes | Yes | Agile tracking tools (Jira, Rally) | DevOps, Agile Program Managers |
Project ID | Sometimes | Maybe | PMO project charters, initiative list | PMO, IT Finance |
Cloud Invoice Data | No (external) | Yes | AWS CUR, Azure billing exports | FinOps, Cloud Ops |
Cost Center | Yes | Maybe | Org finance hierarchy or ops rosters | IT Finance, Department Managers |
Asset Tag / Type | Yes | Maybe | CMDB, asset inventories, facilities logs | Facilities, Asset Management |
Output: A list of interpretable fields and their associated supporting materials and contacts.
Step 2: Match Fields to Viable Mapping Methods
Input: Interpretable fields and reference data from Step 1
Match each viable field to one or more supported mapping methods. Eliminate any mapping methods that you can’t support with the available context.
Mapping Approach | Primary Field(s) | Requires Context From |
Cloud Invoices | Cloud invoice metadata | FinOps, cloud tooling |
Vendors | Vendor name | Procurement, contract owners |
Contracts | Contract ID | Procurement, legal, contract database |
Labor – Agile Teams | Team name | HR, Agile tracking tools |
Labor – Traditional Roles | Role / job title | HR directory |
Cost Centers | Cost center | IT Finance, business units |
Projects | Project ID | PMO, initiative charter |
Fixed Assets | Asset ID, description | CMDB, asset inventory |
Output: A shortlist of viable mapping approaches you can pursue.
Step 3: Score and Prioritize Mapping Methods
Input: Shortlist of viable mapping methods from Step 2
For each method, evaluate the following traits and assign a score from 1 to 3:
Detail | Description | Scoring Criteria |
Field Completeness | How consistently the relevant field is populated across GL records | 1 = <25% of records 2 = 25–75% 3 = >75% |
Reference Availability | Existence and accessibility of documentation needed to interpret field values | 1 = None 2 = Informal or incomplete docs 3 = Trusted, comprehensive references |
Stakeholder Support | Likelihood of engaging a stakeholder who can assist with mappings | 1 = None 2 = Intermittent or uncertain 3 = Active, known support |
Value Uniqueness | Consistency and cleanliness of field values (e.g., same vendor not entered multiple inconsistent ways) | 1 = High duplication/variance 2 = Mixed quality 3 = Clean, standardized, low redundancy |
Quick Tip: For Value Uniqueness, export a sample of GL records and use a pivot table or text grouping to count how many variations exist for what should be the same logical entity.
Quick Tip: If you’re working in a spreadsheet tool like Excel, you can automate this calculation using a formula (e.g., =OriginalAmountCell * AllocationPercentCell). In commercial TBM software, this allocation is typically handled automatically.
- Ensure the sum of the allocation percentages across all duplicated rows totals 100%.
Create a table like the one below, and record the scores for each mapping pass you have assessed. The higher the score, the higher the likelihood of a successful mapping pass.
Mapping Method | Field Completeness (1–3) | Reference Availability (1–3) | Stakeholder Support (1–3) | Value Uniqueness (1–3) | Total Score |
Create a row for each viable mapping approach |
Output: A ranked list of mapping methods to guide your mapping sequence.
Step 4: Review and Begin Mapping
Input: Ranked list of mapping approaches from Step 3
Now that you’ve scored and ranked your available mapping approaches, it’s time to determine the sequence in which you’ll execute them.
Action:
- Review the total scores for each mapping method. These scores reflect your current data readiness and support context for tower mapping.
- If multiple methods have similar scores and it’s difficult to prioritize them, consider:
- Expanding the scoring system to a 5- or 7-point scale for more precision
- Re-evaluating the input data or stakeholder availability
- Establish a sequence of mapping passes, starting with the highest-scoring method.
- Use the mapping guides provided in the following sections to execute each pass.
Important: Between mapping passes, assess how much of your GL dataset has been successfully mapped to towers. You may want to calculate:
- Percent of records mapped by each approach
- Cumulative percent of GL mapped across all approaches so far
- In some cases, a single GL record may be eligible for mapping via multiple approaches (e.g., Vendor and Project). If so:
- Test each mapping method against the full dataset
- Compare the accuracy and confidence of each method
- Retain the mapping approach that yields the most consistent and defensible assignments
Output: A sequenced plan of mapping passes, ready for execution using the detailed walkthroughs that follow.
About Cost Allocations
Mapping a cost to a tower is only part of the work. You may also need to allocate a single GL record across multiple towers or sub-towers. For example, a $100,000 invoice from a managed services vendor may include support for both End User and Application towers.
In these cases, you must:
- Duplicate the original row once for each portion of the allocation (e.g., three duplicates for three sub-towers).
- For each duplicated row, enter the allocation percentage in the Allocation Percent column.
- Multiply the original GL amount by the allocation percent to determine the Allocated Amount for each row.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
- Ensure the sum of the allocation percentages across all duplicated rows totals 100%.
Quick Tip: Mapped records that don’t require splitting across towers should receive an Allocation Percent of 100%.
Allocations are required whenever a single cost line supports multiple towers. Your model is only as accurate as your allocation assumptions. Visit our cost allocation page for more information about allocation types.
Vendor-Based Mapping
Vendor-based mapping is often the first and most effective pass for mapping technology costs to TBM Towers. Many general ledger (GL) records are tied to external suppliers — from hardware vendors and software publishers to managed service providers and staffing firms. These vendors typically provide services aligned to specific towers or sub-towers, making vendor name a powerful and high-confidence mapping field.
- Earlier in your Tower Mapping Plan, you evaluated the Vendor field for completeness, value uniqueness, reference availability, and stakeholder support. Those same reference materials — such as a vendor index, contract summaries, or stakeholder knowledge — now enable your mapping effort.
- This mapping method should be applied to your entire GL dataset, not just unmapped records. This allows for comparison across mapping passes and helps detect overlaps.
Step 1: Identify and Normalize Vendor Names
Most organizations have a Vendor field in the GL. If not, derive the vendor from related data sources, such as:
- Contract master tables (match on Contract ID)
- Procurement system exports
- Accounts Payable payment records
Once identified, normalize vendor names. Inconsistent formats (e.g., “IBM Corp” vs. “I.B.M.” vs. “International Business Machines”) can result in missed mappings.
Quick Tip: Use fuzzy matching, grouping, or manual curation to standardize vendor values. Leverage the Value Uniqueness insight from your planning phase to assess how much cleanup is needed.
Step 2: Build the Vendor Mapping Table
For each unique vendor, define mapping rules that associate their services to a specific Tower and Sub-Tower. Use:
- Known products or services provided
- Contract purpose or scope
- Procurement team input or service owner validation
Record the allocation method used (e.g., fixed %, usage-based), and note any additional rationale in your Tower Mapping Notes column (optional but helpful).
Example Mapping Rules:
- CDW → 100% to End User → Hardware – Devices (Fixed Allocation)
- Cisco → 100% to Network → Network Hardware (Fixed Allocation)
- Infosys → 60% to Application → Development, 40% to Platform → Platform Engineering (Split provided by IT sourcing manager)
Step 3: Apply Mapping Rules to the Entire Dataset
Using your vendor mapping table, apply the appropriate tower and sub-tower mappings to every GL record with a matching vendor.
- If a vendor maps to multiple towers, duplicate the row for each allocation portion.
- Enter the appropriate Allocation Percent for each row.
- Calculate the Allocated Amount.
Add context or decisions to Tower Mapping Notes as needed.
Quick Tip: Mapped records that don’t require splitting across towers should receive anAllocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Vendor | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
Infosys | $100,000 | Application | Development | 60% | $60,000 | Fixed % from sourcing lead | Also mapped in Project ID pass |
Infosys | $100,000 | Platform | Platform Engineering | 40% | $40,000 | Fixed % from sourcing lead |
Step 4: Compare with Other Mapping Passes
After applying vendor-based mappings:
- Identify GL records that were mapped by more than one mapping approach.
- Compare the tower/sub-tower results across methods.
- If mappings differ, determine which approach is more accurate or better supported.
- Update the mapping accordingly and document the decision in the Tower Mapping Notes column.
Quick Tip: Use filters or lookup formulas to identify overlapping mappings. Review accuracy based on source reliability, stakeholder input, or known scope.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level for high-value mappings
This method often produces high-confidence mappings for a large share of your GL. Use it to establish early traction and accelerate mapping momentum before proceeding to your next prioritized pass.
Contract-Based Mapping
Contract-based mapping closely resembles vendor-based mapping but shifts the focus from the supplier to the specific contract that governs the expense. This method is particularly useful when:
- Vendors have multiple contracts tied to different services or business areas
- The contract itself defines the service scope more clearly than the vendor name
- The GL includes a Contract ID field or other linkable field
- If vendor names in your GL are ambiguous or cover diverse services, but you have a reliable Contract ID field with access to supporting documentation, contract-based mapping may offer more precision than vendor mapping.
- Contract and vendor-based mapping should be used together. In many organizations, contracts add granularity to vendor mapping and serve as a second pass to refine or validate tower attribution.
- This mapping method should be applied to your entire GL dataset, not just unmapped records. This enables comparison between mapping passes and supports fallback analysis.
Step 1: Identify and Normalize Contract IDs
Locate the Contract ID field in your GL data. If it does not exist or is sparsely populated, you may be able to derive it using:
- Cross-references to procurement or sourcing systems
- Matching Vendor and Invoice fields to known contracts
- Manual tagging with the help of Procurement or Legal
Ensure Contract ID values are standardized for matching. Variations in format or ID structure can cause mismatches or failed joins.
Quick Tip: If your planning step flagged high value uniqueness for Contract ID, normalization should be straightforward. If not, review a sample of values with Procurement to align formats.
Step 2: Build the Contract Mapping Table
Create a table that maps each known Contract ID to a Tower and Sub-Tower, along with:
- The type of service covered by the contract
- Stakeholder input (e.g., contract owner or service owner)
- Allocation method: fixed %, usage-based, or other rationale
- Any known mapping conflicts or special cases
Add notes to the Tower Mapping Notes column as needed, especially for contracts that:
- Overlap with vendor-based mappings
- Apply to more than one tower
- Are part of a shared service arrangement
Quick Tip: Mapped records that don’t require splitting across towers should receive anAllocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Step 3: Apply Contract Mapping to the Entire Dataset
Using your contract mapping table:
- Apply tower and sub-tower mappings to every GL record with a matching Contract ID
- Duplicate rows when splitting allocations across multiple towers
- Assign Allocation Percent and calculate Allocation Amount
- Use Tower Mapping Notes to capture overlapping mappings or manual decisions
Contract ID | Vendor | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
C-1083 | Infosys | $75,000 | Application | Development | 100% | $75,000 | Contract scope review | Clean match; validated by app owner |
C-2011 | Accenture | $200,000 | Strategy | Architecture | 50% | $100,000 | Fixed % split from sourcing | Also mapped via Project ID |
C-2011 | Accenture | $200,000 | Platform | Cloud Engineering | 50% | $100,000 | Fixed % split from sourcing |
Step 4: Compare with Other Mapping Passes
After applying contract-based mappings:
- Identify records mapped by multiple methods
- Compare Tower/Sub-Tower results across methods
- If mappings differ, select the most accurate or supported assignment
Note changes or overrides in the Tower Mapping Notes column
Quick Tip: A single GL line might be mapped by contract and vendor methods. Use Tower Mapping Notes to retain traceability.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level for high-value mappings
This pass is particularly helpful for organizations with a strong procurement function and well-maintained contract metadata. It can validate or refine vendor mappings, and bring additional precision to the tower attribution process.
Cost Center–Based Mapping
Cost center–based mapping leverages organizational structure and financial ownership to attribute technology spend to TBM Towers. When cost centers are functionally aligned with services or teams (e.g., a Networking department), they can serve as a strong mapping signal. This approach is especially useful when internal teams are the primary service providers rather than external vendors.
- Earlier in your Tower Mapping Plan, you assessed the Cost Center field for completeness, value uniqueness, available references (e.g., org charts, rosters), and stakeholder support. These same resources now support your mapping effort.
- Apply this mapping method to your entire GL dataset, not just the unmapped portion. This ensures comparability across mapping passes and supports overlap detection.
Step 1: Review and Normalize Cost Center Values
Begin by reviewing the Cost Center values in your GL and related systems. Clean and standardize these values for consistency:
- Normalize names or IDs
- Resolve abbreviations and alternate formats
- Map legacy codes to current equivalents (if applicable)
Quick Tip: Use your Value Uniqueness score from the planning phase to identify values needing standardization. Fewer distinct values usually indicate less cleanup.
Step 2: Build the Cost Center Mapping Table
For each unique cost center, define a mapping rule to one or more Tech Resource Towers and Sub-Towers. Use:
- Organizational charts and team responsibilities
- Department-level budget ownership
- Interviews with cost center managers or HR partners
If a cost center supports multiple services, create fixed allocation percentages and document your reasoning in the Tower Mapping Notes column.
Example Mapping Rules:
- Network Ops CC123 → 100% to Network → Network Operations (Fixed Allocation)
- IT Shared Services CC234 → 50% to Platform → Platform Engineering, 50% to Security → Security Operations (Split allocation from finance partner)
Quick Tip: Mapped records that don’t require splitting should receive an Allocation Percent of 100%.
Step 3: Apply Mapping Rules to the Entire Dataset
Join your cost center mapping table to your GL dataset. For each matching record:
- Populate Tower and Sub-Tower fields
- Duplicate records for each split allocation
- Enter Allocation Percent values
- Calculate Allocation Amounts as GL Amount × Allocation %
- Capture notes or conflicts in the Tower Mapping Notes column
Quick Tip: Keep a separate copy of the GL for each mapping pass and one consolidated view across all passes. This helps with overlap analysis and tracking unmapped records.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Cost Center | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
CC123 | $50,000 | Network | Network Operations | 100% | $50,000 | Fixed % from org chart | Also mapped in Project ID pass |
CC234 | $80,000 | Platform | Platform Engineering | 50% | $40,000 | Split % from finance lead | Shared with Security Ops |
CC234 | $80,000 | Security | Security Operations | 50% | $40,000 | Split % from finance lead | Shared with Platform Eng |
Step 4: Compare with Other Mapping Passes
Check for records that have been mapped by multiple approaches (e.g., Vendor and Cost Center):
- Identify overlaps
- Compare tower/sub-tower results
- Decide which mapping is more accurate or better supported
- Update mapping fields accordingly
- Document rationale in Tower Mapping Notes
Quick Tip: Use lookup formulas or conditional formatting to flag overlapping records.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level for high-value mappings
Cost center mapping often covers large portions of internal spend. It is especially effective when external vendor data is sparse or unclear.
Cloud Invoice-Based Mapping
Cloud invoice-based mapping is essential for organizations with significant cloud spend. Unlike traditional technology costs, cloud charges are often usage-based, dynamic, and highly granular. Mapping these costs requires specialized data parsing, alignment with FinOps practices, and knowledge of cloud-native terminology.
- While conceptually similar to vendor or contract mapping — associating a record with a known service provider — this pass demands a deeper understanding of cloud billing constructs and often involves joining across multiple systems.
- Earlier in your Tower Mapping Plan, you evaluated whether cloud invoice fields were present and interpretable. The quality of that data — along with available FinOps support and tagging strategies — directly influences the effectiveness of this mapping pass.
Step 1: Acquire and Understand Cloud Invoice Data
Start by collecting usage and billing exports from your cloud provider (AWS, Azure, GCP). Key data sources include:
- AWS Cost and Usage Report (CUR)
- Azure Detailed Usage Report
- GCP Billing Export (BigQuery or CSV)
Familiarize yourself with the key fields, which may include:
- productCode, usageType, serviceName, resourceId
- linkedAccountId, billingAccountId, projectId
- Custom tags or labels
Quick Tip: Work closely with your FinOps team or cloud operations lead to understand these fields and identify mapping opportunities.
Step 2: Normalize and Tag Invoice Data
Cloud invoices do not directly reference GL line items. You will need to:
- Normalize service names (e.g., map “AmazonEC2” to Compute → IaaS)
- Create mapping rules based on productCode, usageType, or tags
- Add columns for Tower and Sub-Tower using your mapping logic
If your organization uses FinOps practices, leverage:
- Tag dictionaries (team, environment, service)
- Linked account-to-business unit mappings
Remember: Tag hygiene is critical. Unused or inconsistent tags lead to unmapped spend.
Step 3: Join Cloud Data to GL and Populate Mapping Fields
Match invoice records to GL records using shared fields, such as:
- Cost center
- Account ID
- Project or product tags
Apply tower and sub-tower mappings based on the invoice mapping table. Document your logic and assumptions in the Tower Mapping Notes column.
Quick Tip: Just like other mapping passes, apply this method to the full dataset. Even partial matches can contribute meaningfully.
Step 4: Validate and Reconcile
Reconcile mapped invoice totals against GL cloud spend:
- Ensure totals match by provider, service category, or cost center
- Identify gaps, unmapped items, or shared service costs
- Review allocation logic for platform services or shared infrastructure
Quick Tip: Use visual tools or pivot tables to explore anomalies and validate expected allocations.
Step 5: Compare and Track Mapping Progress
Review mapping progress:
- Compare cloud invoice mappings against other passes (e.g., Vendor, Project)
- Resolve overlaps and determine the most accurate mapping
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level for high-value mappings
Cloud invoice mapping can be highly accurate when supported by clean tagging and mature FinOps practices. It’s an essential pass for organizations with large or growing cloud footprints.
Agile Team-Based Labor Mapping
Agile labor mapping focuses on attributing labor expenses to TBM Towers based on Agile teams. This method is most effective in organizations where persistent Agile teams (e.g., squads, pods, trains) are well-documented, named, and consistently aligned to solutions, services, or platforms.
- Earlier in your Tower Mapping Plan, you evaluated the Agile Team field for completeness, value uniqueness, availability of reference materials (like team rosters), and stakeholder support. These same inputs now help drive this mapping effort.
- Agile team-based mapping is distinct from traditional labor mapping. Here, the unit of analysis is the team, not the individual. It assumes each team has a relatively stable composition and mission. This enables you to map the cost of all team members as a group to the appropriate tower(s).
- As with other mapping passes, apply this approach to your entire GL dataset, not just the unmapped portion. This supports better overlap detection and improves traceability.
Step 1: Identify Agile Teams in Your GL or Labor Records
Your GL may include a field like Agile Team, Squad Name, or Team ID. If not, you may need to:
- Join to time tracking or Agile tooling (e.g., Jira, Rally, Azure DevOps)
- Match on Employee ID to HR or Resource systems that contain team assignments
- Work with Agile program leads to derive team associations
Note: Incomplete or stale team assignments may need to be manually reviewed. Use the team roster data you identified earlier in your planning phase.
Step 2: Create the Agile Team Mapping Table
For each team, define which tower or towers their work supports. This may be based on:
- Team charters or product ownership
- Team-to-solution mapping matrices
- Interviews with product owners, Scrum Masters, or RTEs
If a team supports multiple towers, determine allocation percentages. Document all mappings, allocation methods, and justifications.
Quick Tip: Mapped records that don’t require splitting across towers should receive an Allocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Step 3: Apply Mappings to the Dataset
Using your team mapping table:
- Add the mapped Tower and Sub-Tower values
- Duplicate rows for split allocations, applying the correct Allocation Percent and computing Allocated Amount
- Include context in the Tower Mapping Notes column, such as team ambiguity, mapping rationale, or overlap with other passes
Quick Tip: Create a dedicated copy of your GL for this mapping pass, and maintain a consolidated version for cumulative tracking.
Agile Team | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
Team Zephyr | $200,000 | Application | Development | 100% | $200,000 | Team charter and product matrix | May overlap with Vendor-based mapping pass |
Team Orion | $120,000 | Platform | Platform Engineering | 60% | $72,000 | Allocation from RTE | Shared team with Infrastructure |
Team Orion | $120,000 | Infrastructure | Hosting Compute | 40% | $48,000 | Allocation from RTE | Shared team with Platform |
Step 4: Compare and Reconcile with Other Passes
- Use filters or lookups to find records also mapped in other passes
- If conflicting mappings exist, determine the most accurate one based on available evidence
- Document decisions in Tower Mapping Notes and update the consolidated GL copy accordingly
Reminder: Comparing results ensures that labor costs are not duplicated or misattributed across mapping passes.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level for each team mapping (based on team charter clarity, stakeholder validation, etc.)
Agile team mapping is especially effective for Agile-mature organizations. When supported by good documentation and stakeholder engagement, it provides a clear, scalable method for labor attribution.
Traditional Labor-Based Mapping
Mapping labor costs based on individual employees is particularly useful when Agile team structures are not consistently applied across the organization, or when traditional departments, roles, or individuals can be directly associated with specific Towers or Sub-Towers. This approach focuses on using individual-level fields — like job title, name, or employee ID — to assign technology labor spend.
- Earlier in your Tower Mapping Plan, you evaluated fields like Job Title and Employee ID for interpretability, completeness, and stakeholder support. The mappings and reference materials collected during that step (e.g., HR job code dictionaries, role definitions, or manager input) now serve as your foundation for this pass.
- Apply this mapping approach to your entire GL dataset, not just the unmapped records. This ensures visibility into overlaps with other passes and supports broader reconciliation.
Step 1: Identify and Normalize Contract IDs
Locate the Contract ID field in your GL data. If it does not exist or is sparsely populated, you may be able to derive it using:
- Cross-references to procurement or sourcing systems
- Matching Vendor and Invoice fields to known contracts
- Manual tagging with the help of Procurement or Legal
Ensure Contract ID values are standardized for matching. Variations in format or ID structure can cause mismatches or failed joins.
Quick Tip: If your planning step flagged high value uniqueness for Contract ID, normalization should be straightforward. If not, review a sample of values with Procurement to align formats.
Step 2: Create the Labor Mapping Table
For each distinct job title or individual (depending on data availability), define mapping rules that associate labor with one or more Towers and Sub-Towers. Base your mapping logic on:
- Standard role-to-tower alignments (e.g., “Database Administrator” → Platform → Data Management)
- Known responsibilities from HR documentation or manager input
- Departmental functions (if roles are unclear)
Use the Tower Mapping Notes column to log rationale, uncertainties, or multiple-approach overlaps.
Quick Tip: Mapped records that don’t require splitting across towers should receive anAllocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Step 3: Apply Mapping Rules to the Entire Dataset
Using your labor mapping table:
- Apply tower and sub-tower mappings to all GL records with employee or job title data
- Duplicate rows for allocations split across multiple towers
- Enter Allocation Percent and calculate Allocated Amount
- Note overlaps or confidence levels in the Tower Mapping Notes column
Job Title | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
Database Administrator | $90,000 | Platform | Data Management | 100% | $90,000 | HR job role standard | Only mapped here |
IT Support Specialist | $60,000 | End User | Support Services | 100% | $60,000 | Department alignment | Also appears in Cost Center pass |
Quick Tip: Use a dedicated copy of your GL for this pass, and keep a consolidated version that tracks which records are mapped across all passes.
Step 4: Compare with Other Mapping Passes
After applying the individual labor mappings:
- Identify GL records also mapped by other approaches (e.g., Cost Center, Projects)
- Compare tower/sub-tower results
- If results differ, select the most accurate mapping and document your rationale
Quick Tip: Individual labor mapping often overlaps with cost center-based mapping — be cautious when roles are broadly defined.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level (e.g., based on job title clarity or stakeholder input)
This mapping approach provides broad labor coverage and is especially valuable when Agile or project-based structures are incomplete or inconsistent.
Project-Based Mapping
Project-based mapping leverages the association between GL records and Project IDs to determine the appropriate Technology Resource Towers and Sub-Towers. This method is particularly useful when your organization tracks spend by initiatives, programs, or capital projects that have clear scopes aligned to business capabilities or technology services.
- Earlier in your Tower Mapping Plan, you evaluated the Project ID field for completeness, uniqueness, stakeholder support, and reference availability. That preparation now enables effective mapping.
- Project-based mapping shares similarities with vendor and contract mapping. However, while vendor-based mapping focuses on the external provider and contract-based mapping centers on the legal agreement, project-based mapping is guided by the intended outcome or work effort funded by the spend.
- As with all mapping methods, this should be applied to your entire GL dataset, not just unmapped records. This allows for overlap comparisons and more complete tower attribution.
Step 1: Validate and Standardize Project Identifiers
Ensure the GL includes a populated and standardized Project ID field. If not, look to enrich the dataset by:
- Joining with project management system exports
- Linking to capital expenditure reports or initiative logs
- Consulting the PMO or finance teams for project code crosswalks
Quick Tip: If project names or IDs vary slightly across systems, work with the PMO to define consistent identifiers and consolidate duplicates.
Step 2: Build the Project Mapping Table
For each unique Project ID:
- Define the associated Tower and Sub-Tower(s)
- Reference initiative scope, business case, or technical charter
- Consult the PMO, solution owners, or finance partners for confirmation
- Use your Tower Mapping Notes column to document any assumptions or exceptions
Example Mapping Rules:
- PRJ1003 → 100% to Application → Testing Services
- PRJ2021 → 50% to Platform → Hosting, 50% to Platform → Platform Engineering
- PRJ3399 → 100% to Data → Data Platforms (from business case)
Quick Tip: Mapped records that don’t require splitting across towers should receive anAllocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Step 3: Apply Project Mapping Rules to the Dataset
Using your project mapping table:
- Apply mappings to every GL record with a matching Project ID
- Duplicate rows for split allocations
- Assign Allocation Percent and calculate Allocation Amount
- Use the Tower Mapping Notes column to indicate overlaps or special considerations
Project ID | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
PRJ2021 | $50,000 | Platform | Hosting | 50% | $25,000 | PMO-validated scope | Also mapped by Vendor (AWS) |
PRJ2021 | $50,000 | Platform | Platform Engineering | 50% | $25,000 | PMO-validated scope |
Reminder: Records not requiring allocation splits should still receive 100% in the Allocation Percent column.
Step 4: Compare Against Other Mapping Passes
After completing this pass:
- Identify records with tower mappings from more than one approach
- Review and resolve any discrepancies between methods
- Choose the most accurate or supported mapping and document the rationale
Tip: Keep a dedicated GL copy for each mapping pass and a consolidated version to track cumulative coverage and overlaps.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total spend mapped in this pass
- % of total GL records covered
- Confidence level especially where projects had clear scope
Project-based mapping is especially valuable when aligned to initiative portfolios or funded work. It can offer precise mapping for capital investments, major programs, or transformation efforts.
Fixed Asset-Based Mapping
Fixed assets, such as servers, networking gear, and end-user devices, often represent large capital investments that continue to generate depreciation and amortization expenses over time. Mapping these costs to Towers and Sub-Towers ensures that the capital portion of your technology stack is accurately reflected in your TBM model.
- In your Tower Mapping Plan, you assessed the interpretability and availability of fixed asset fields (e.g., Asset Type, Asset Category, Tag Number). That foundational work now informs this mapping pass.
- Like all mapping passes, this method should be applied to your entire GL dataset, not just the unmapped records. Doing so helps identify overlaps and improves allocation consistency across all technology resources.
Step 1: Identify Fixed Asset Fields
Look for asset-related fields in your GL or enrich the data with an asset subledger. Common fields include:
- Asset ID
- Asset Description
- Asset Category or Class
- Location
- Department or Cost Center
If these are unavailable, reach out to your asset accounting team or facilities group.
Quick Tip: Ensure assets are still in use and relevant. Decommissioned assets may still appear due to ongoing depreciation but may no longer align with operational towers.
Step 2: Create the Asset Mapping Table
For each Asset Category or individual Asset (depending on granularity), define tower and sub-tower mappings based on:
- Asset type (e.g., Server → Compute → IaaS)
- Deployment purpose (e.g., End User → Devices)
- Known locations or business functions
Log assumptions, exceptions, or overlapping methods in the Tower Mapping Notes column.
Quick Tip: Mapped records that don’t require splitting across towers should receive anAllocation Percent of 100%.
Quick Tip: If you’re working in a spreadsheet, use a formula to calculate the Allocation Amount as: Allocation Amount = [GL Amount] * [Allocation Percent]
Most commercial TBM tools will handle this automatically.
Step 3: Apply Mapping Rules to the Entire Dataset
Apply tower and sub-tower mappings from your asset mapping table to all applicable GL records:
- Duplicate rows if splitting costs across multiple towers
- Add Allocation Percent and compute Allocated Amount
- Document overlaps or caveats in Tower Mapping Notes
Asset Category | Amount | Tech Resource Tower | Tech Resource Sub-Tower | Allocation % | Allocation Amount | Allocation Method / Source | Tower Mapping Notes |
Servers | $150,000 | Compute | IaaS | 100% | $150,000 | Fixed asset category | Mapped via Asset ID |
Laptops | $50,000 | End User | Devices | 100% | $50,000 | Asset ledger rule | Also mapped in Vendor-based pass |
Quick Tip: Keep a separate GL copy for this pass and a consolidated version across passes to simplify overlap detection.
Step 4: Compare with Other Mapping Passes
After applying asset-based mappings:
- Identify records also mapped by other passes (Vendor, Cost Center, etc.)
- Compare mapping outputs and rationale
- Resolve differences by selecting the most accurate source and documenting why
Quick Tip: Vendor and Contract passes often intersect with capital purchases — be especially careful when comparing these mappings.
Step 5: Track Mapping Progress
Maintain key metrics:
- Total fixed asset spend mapped in this pass
- % of total GL records covered
- Confidence level for high-value mappings
This pass ensures capital investments are appropriately reflected in your tower allocations, especially for infrastructure-intensive environments.
Join the TBM community: where innovators and leaders converge
The TBM Council is your gateway to a treasure trove of knowledge: think cutting-edge research papers, insightful case studies, and vibrant community forums where you can exchange ideas, tackle challenges, and celebrate successes with fellow practitioners.
We’re calling on organizations and forward-thinking individuals to dive into the TBM community. Participate in our events, engage in our discussions, and tap into a vast reservoir of knowledge. This isn’t just about networking; it’s about contributing to and benefiting from the collective wisdom in navigating the dynamic world of cloud computing.
