Executive answer
An allocation key distributes common costs among recipients where sufficient direct tracing is unavailable. It should reasonably approximate each entity’s expected benefit, use controlled data and permit another person to reproduce the calculation. It is not defensible merely because it is common, simple or historical. Revenue, headcount and assets are possible indicators, not universal answers.
Selection comes after defining the service, establishing benefit and cleaning the base. A perfect key applied to shareholder costs, unperformed services or duplication only distributes an improper charge accurately. The percentage also does not determine the complete price: the pool, pass-through treatment, mark-up, currency, adjustments and terms must be analyzed.
A sound process has six steps: segment services, identify the benefit driver, evaluate direct measures, select a proxy, test data and results, and document governance. When services have different drivers, split them or use multiple keys with a clear reconciliation.
Matching principle
The central question is: which variable changes approximately in the same direction as consumption or expected benefit? Payroll may follow employees processed; user technology may follow users, devices or tickets; accounts payable may follow invoices; procurement may follow managed spend; treasury may follow balances, debt or transactions; premises may follow floor area.
The indicator need not measure economic value with scientific precision. It must have an explainable, stable relationship. Use available information where reliable, but do not sacrifice correspondence solely for convenience. If the ideal measure does not exist, explain why the selected proxy is better than reasonable alternatives.
Define the key ex ante, before seeing which company receives the largest charge. Retrospectively choosing the variable that minimizes Mexico’s share creates bias. Maintain a selection policy, change criteria and approvals.
Static key selector
| Family | Expected driver | Possible primary key | Alternative | Misapplication risk |
|---|---|---|---|---|
| Human resources | population served | employees/FTE | payroll changes | including personnel outside scope |
| Payroll | processing | payslips or employees processed | hours | ignoring country complexity |
| End-user IT | access/support | users or devices | weighted tickets | counting inactive licenses |
| IT infrastructure | capacity | consumption, storage, CPU | users | missing reserved capacity |
| Accounts payable | volume | invoices processed | vendors | mixing simple and complex invoices |
| Procurement | managed activity | orders or spend | savings | including unmanaged spend |
| Treasury | funds/risk | balances, debt, transactions | assets | mixing cash pool and loans |
| Legal | matter/time | hours or cases | revenue | spreading one entity’s litigation |
| Compliance | duty/risk | hours or covered entities | revenue | confusing shareholder governance |
| Marketing | market/campaign | spend, users or linked sales | revenue | assuming uniform benefit |
| Facilities | occupancy | square meters | headcount | ignoring exclusive areas |
| General management | mixed benefit | justified composite | revenue | defaulting to revenue |
The table is a starting point. Conduct and contractual scope decide. Users may fit an application, while consumed capacity may fit cloud infrastructure. “IT” should not be one pool when it combines both models.
Direct trace before allocation
Costs attributable to one recipient should be direct where systems allow. A Mexico-only project should not be spread globally and return merely in proportion to revenue. Direct tracing reduces cross-subsidies and improves evidence.
Define required fields: project, internal customer, cost center, order, ticket or code. Train providers to record them as cost is incurred, not months later. Review samples and “unassigned” rates. A sophisticated system has little value if staff use generic categories.
The residual forms the common pool. Explain the boundary between direct and indirect. An employee may record project hours directly and leave general supervision in common. Prevent double counting: a directly assigned item must not remain in the pool.
Build and clean the pool
Start with a population reconciled to the provider’s ledger. Identify accounts, centers, entities, currency and period. Remove shareholder, duplicate, unperformed and out-of-scope costs. Separate pass-through items and costs earning a mark-up according to the functional analysis.
Negative costs, recoveries and provisions need rules. Decide whether they reduce the pool, belong to another period or represent adjustments. Document capitalization, depreciation, bonuses, travel and taxes. Year-to-year consistency matters, but an incorrect historic policy should be corrected with an explanation.
Where several entities contribute, map the layers. A regional center may receive a global charge and add its own costs. Preserve the path from original account to final recipient and avoid successive mark-ups without analyzing value added.
Data quality
A defensible key needs an authorized source, definition, owner, extraction date, period, currency where relevant, controls and integrity evidence. “Headcount supplied by HR” is insufficient if nobody knows whether it means average, year-end, FTE, contractors or all employees.
Use comparable denominators. If Mexico reports an annual average and others report closing counts, the shares are distorted. Document entities with missing data, acquisitions, disposals or inactivity. Do not automatically assign zero: a start-up entity can consume substantial support despite low revenue.
Reconcile totals to operating or financial reports. Control duplicates, nulls and large movements. A dashboard may alert deviations, but retain source files and transformations. Version formulas and protect critical cells.
Simple, multiple and composite keys
A simple key works where the service is homogeneous and one driver dominates. It is transparent and easy to operate. Multiple keys use different variables for separated components—for example, users for IT and invoices for payables. Costs must be segmented before distribution.
A composite key weights several variables in one service, such as 50% users, 30% tickets and 20% devices. It may better reflect benefit, but adds judgment and manipulation risk. Support each weight with analysis rather than the desired result. Test sensitivity.
Do not confuse sophistication with quality. With weak data, a complex formula amplifies errors. Prefer the simplest model retaining a reasonable relationship and capable of regular operation.
If one revenue key allocates HR, IT, legal and treasury, segment the pool and compare drivers before the next charge.
Reasonableness tests
Review absolute and relative outcomes. Does an entity with no employees receive HR? Does an entity with its own platform bear full global IT? Did Mexico’s share jump because of currency or real consumption? Compare with prior year, budget, usage and operating explanations.
Run sensitivity using one or two reasonable alternatives. The objective is not the lowest charge, but understanding dependence on judgment. A material difference requires stronger documentation or better data.
Test excluded beneficiaries. If an entity received outputs but was omitted from the denominator, others subsidize it. Review zero results, outliers and manual overrides. Obtain local owner confirmation.
Prove the total allocated reconciles exactly to the pool before mark-up and after adjustments. Explain rounding and currency. The control should trace both ways: invoice to original account and account to invoices.
Key file
| Document | Minimum content | Owner |
|---|---|---|
| Policy | services, method, frequency, exceptions | tax/TP |
| Catalogue | scope and recipients | business |
| Cost bridge | ledger to cleaned pool | provider finance |
| Selection memo | driver, alternatives, conclusion | TP |
| Data dictionary | definition, source, period | data owner |
| Extract | original file and date | systems/finance |
| Calculation | formulas, denominator, shares | controlling |
| Tests | movements, outliers, sensitivity | tax |
| Approval | owners and exceptions | committee |
| Reconciliation | calculation to invoice, entry, payment | accounting |
Retain versions. A final spreadsheet without source data and decisions cannot be reproduced. Avoid broken links to personal folders.
Changes and year-end adjustments
The key may be estimated during the year and updated with actual data. The policy should state frequency, threshold and true-up treatment. An adjustment should not surprise recipients or retrospectively change the logic to reach a target margin.
Business changes require review: acquisition, disposal, ERP migration, centralization, automation, new platform or changed scope. Separate a method change from a data refresh. The first needs support and approval; the second follows policy.
At year-end, reconcile population, pool, key, mark-up, invoices and accounting. Determine the tax and documentation effects of the adjustment. Retain estimates and actual results and explain differences.
Common errors
- Using revenue for every service.
- Selecting the key after observing the outcome.
- Spreading directly traceable costs through a common pool.
- Keeping non-beneficiaries in the denominator.
- Excluding beneficiaries because data are missing.
- Mixing closing and average headcount.
- Failing to remove shareholder or duplicate costs.
- Marking up every item without analysis.
- Using complex formulas without source controls.
- Changing the key annually without explanation.
- Failing to reconcile totals to invoices and ledger.
- Documenting percentages but not benefit.
Practical implementation
In week one, catalogue services and map cost centers. In week two, clean the pool and identify direct measures. In week three, assess keys, data quality and sensitivity. In week four, approve policy, run a pilot and reconcile to records.
Appoint a service owner and a data owner. The first validates benefit; the second validates variable integrity. Tax and transfer pricing review classification and method. Accounting operates billing and true-ups. Legal checks that the agreement describes allocation.
The goal is not an eternal formula. It is a repeatable control that changes when facts change and retains sufficient history to explain each invoice.
Worked example: regional IT support
Suppose one cost center contains application licenses, help-desk personnel, cloud capacity and a Mexico-only implementation. First assign the implementation directly to Mexico. Next separate licenses and allocate them to active users, not all registered accounts. Allocate the help desk using weighted tickets if incident complexity differs materially, or users where ticket data are unreliable. Allocate cloud infrastructure through measured consumption or reserved capacity. Remove parent governance and obsolete subscriptions before any distribution.
Reconcile each sub-pool to accounts, apply the supported mark-up only where appropriate, and combine the recipient results in one invoice schedule. Compare the outcome with a single revenue key. A large difference is not proof the segmented approach is right, but it shows why the old proxy needs reconsideration. Record the data limitation, chosen measure and owner.
Document error handling as well. If an entity reports incorrect data, retain the original extract, correction, approval and invoice effect. A traceable correction strengthens control; silently overwriting the file weakens it.
Sources and cutoff
This article was verified as of August 2, 2026. Consult the current Mexican Income Tax Law, OECD country profile for Mexico and OECD Transfer Pricing Guidelines 2022. Selection must follow facts, Mexican law and applicable obligations; the table does not prescribe a mandatory key.
Zugzwang’s Allocation Key Review examines the catalogue, pool, drivers, sources, sensitivity and reconciliation to turn a historical allocation into a reproducible, explainable calculation.