What is ITFM?

The better answer to what is ITFM lives in the month-end close, because that is where the discipline either produces numbers the CFO can act on or produces a slide. So this post walks one close cycle the way a practitioner lives it: the GL feed on day one, the mapping rules that sort it into Cost Pools, the re-tagging week nobody budgets for, the allocation into Resource Towers, and the report that has to survive its own review meeting.

Day one: the GL feed lands and the mapping rules earn their keep

The close starts when finance drops the general ledger extract: thousands of lines of payroll journals, vendor invoices, cloud bills, license true-ups, and accruals. ITFM's first job is GL mapping, sorting every line into a Cost Pool. In practice that runs as a sequence of passes. Vendor-based mapping goes first because it carries the highest confidence; the vendor name usually tells you whether a line is Hardware, Software & SaaS, or Outside Services. Cost center rules pick up much of the remainder, and account-based rules sweep what is left.

A healthy mapping run reports three things: what percentage of lines mapped, which rule mapped each one, and what fell into the residual. The residual is the tell. A process or a tool that quietly defaults unmapped lines into a miscellaneous pool is not finishing the job, it is hiding it, and the hidden lines resurface as unexplainable variance two quarters later. The Technology Business Management (TBM) Council maintains reference guidance on allocation methods that is worth holding your own rules against (allocation methods, TBM Council).

What good looks like at this step is worth stating, because most organizations have never seen it. Mapping rules are governed artifacts: versioned, owned, and reviewed when vendors, cost centers, or account structures change, not rediscovered when a variance goes wrong. Rule coverage is a published metric, tracked month over month, so a slipping percentage gets attention before it becomes a reporting problem. And the first-pass mapping rate is treated the way an engineering team treats build success: when it drops, something changed upstream, and the change is worth finding before it compounds.

The re-tagging week nobody budgets for

Then the exceptions start. A new vendor arrives with no rule behind it. Procurement renamed a cost center mid-quarter and half its history went dark. A managed services invoice spans two Resource Towers and needs allocation percentages that someone has to defend. The fix an analyst made last month lived in a spreadsheet and did not persist into this month's run. This is the real first week of every close, and it is staffed by whoever is most senior enough to know the estate and junior enough to be assigned to it.

That effort is measurable. At one FogLifter® deployment, the team recovered 100+ man-hours per month on storage reporting after validation and reconciliation were put in place. That is a figure from a single deployment and a single reporting domain, not a benchmark, and process change contributed alongside the tooling. What it tells you is the order of magnitude of manual reconciliation hiding inside the phrase just close the month, in one domain of many.

From Cost Pools to Resource Towers: money meets the estate

Once the ledger is classified, Cost Pools allocate into Resource Towers, and this is where money meets the estate. The allocations run on drivers: server counts route spend into Compute, capacity routes it into Storage, headcount and ticket volumes route the service Towers. Every driver is a count from somewhere, usually the CMDB (configuration management database) or the ITAM (IT asset management) repository, which means the accuracy of the allocation is exactly the accuracy of the count. If the CMDB and ITAM disagree on how many servers exist, the Tower totals are wrong before the arithmetic starts.

This is where ITFM quietly depends on data validation, whether or not anyone calls it that. FogLifter's Validation View exists for this step: it reconciles what the CMDB says against what ITAM says and what the invoices bill, before those counts become denominators (see why).

The report the CFO reads, and the questions it has to survive

The visible output of all this is unglamorous: spend by Cost Pool against plan, Tower trends, a page of variance lines. The test of the close is not whether that report renders. It is the follow-up question. When the CFO asks why Software & SaaS is up, the answer either walks back to specific GL lines and specific count changes in the meeting, or it becomes an action item, and an action item is a small resignation letter for the number. A close that produces reports faster but answers questions no faster has not improved.

The close also feeds forward. The forecast for next quarter starts from this quarter's actuals, so every mapping defect and every drifted count gets compounded into the plan the CFO will hold IT to in three months. This is why close quality is a forecasting issue and not only a reporting one: an ITFM practice that closes on unvalidated data is misexplaining the past and building the next plan on the same defects. A practice that closes on validated Cost Pool data starts every forecast from a number that has already survived challenge.

So what is ITFM? Defensible counting, month after month

ITFM is the discipline that turns GL lines into technology cost figures that survive challenge: mapping into Cost Pools, allocating into Resource Towers on validated counts, and doing it again every month without the rules drifting. Everything else, the forecasting, the governance, the CFO partnership, stands on that. If you are evaluating tooling for the job, the anchor whitepaper walks the five tests that decide it. This week: pull last month's mapping run and check two numbers, the percentage mapped and the size of the residual. If nobody can produce either, that is the finding.

See what validated data changes about the close: financial visibility with FogLifter.

Frequently Asked Questions