Apportionment Starts With Data You Do Not Collect
The formula is published and the arithmetic is simple. The reason apportionment takes weeks is that the ledger records where an invoice was raised, not where the customer received the benefit.
State apportionment divides a multistate business's income among states using a formula, most commonly based on the share of receipts sourced to each state and in some states also payroll and property. The difficulty is not the formula but the sourcing data: determining where a receipt belongs requires knowing where the customer received the benefit, which the general ledger typically does not record.
- The formula is published. The work is producing receipts, payroll and property by state from systems that do not think in those terms.
- Sourcing rules differ by state and by type of receipt, and services and intangibles are considerably harder than goods.
- Billing address is a convenient proxy and frequently the wrong answer, particularly for services delivered to multiple locations.
- Payroll and property factors need location detail that HR and fixed asset registers hold inconsistently, especially for remote workers.
- ChatFin assembles the factor data from the ledger, customer master and payroll, and flags the receipts where sourcing is ambiguous rather than guessing.
Apportionment has an unusual property among tax computations. The rules are public, the formula is arithmetic, and the answer is nonetheless expensive to produce.
The reason is that the inputs do not exist in the shape the formula requires. A receipt has to be sourced to a state based on where the customer received the benefit of the service or where the goods were delivered, and the ledger records neither. It records a customer, an invoice, an amount and possibly a billing address that belongs to a procurement office in a different state entirely. Payroll needs to be attributed to where work was performed, which for a distributed workforce is not the same as where the employee is on the payroll register.
This page treats apportionment as the data problem it is: what each factor requires, where sourcing goes wrong, what to do with ambiguity, and how to assemble the data set once so it refreshes each year rather than being rebuilt.
What each factor requires
The factors look similar in a formula and require entirely different data. Treating them as one data request is why the exercise stalls.
| Receipts factor | Revenue sourced to each state under that state's rules, which for services generally means where the benefit was received |
| Payroll factor | Compensation for services performed in each state, which for distributed workers is not the payroll registration state |
| Property factor | Average value of real and tangible personal property in each state, including rented property at a multiple of annual rent |
| Weighting | How the factors combine, which varies by state and increasingly favours a single receipts factor |
| Throwback and throwout | Rules affecting receipts not taxable in the destination state, which change the answer materially where they apply |
The receipts factor now carries most of the weight in many states, which concentrates the difficulty precisely where the data is worst, because service receipts are the hardest to source and the least likely to have location detail attached.
Where sourcing goes wrong
Sourcing is where the judgement sits, and the shortcuts taken under time pressure are consistent across organisations.
Billing address
Used because it exists in the customer master. It frequently identifies a shared services or procurement location rather than where the benefit was received.
Ship to for services
Applying a goods concept to services. There is no shipment, and the delivery location concept has to be constructed from the engagement itself.
Single location for multi state customers
A customer receiving a service across many locations sourced entirely to headquarters, which distorts several states at once.
Prior year percentages
Rolling forward last year's apportionment because the data is unavailable. Defensible only as a stated estimate, and rarely stated as one.
Shortcut three is the most consequential for service businesses. Where a customer receives the benefit across multiple states, a reasonable allocation is generally required, and defaulting everything to one location is both wrong and easy for an examiner to identify.
What to do with genuine ambiguity
Some receipts cannot be sourced precisely from available data, and pretending otherwise is worse than acknowledging it. The practice that survives examination is a documented, consistently applied method rather than a precise looking number with no basis.
The fourth point converts an uncomfortable uncertainty into a manageable one. Knowing that a defined share of receipts is sourced on an allocation basis, and what the sensitivity is, is a far stronger position than a computation that looks exact and cannot be explained.
What the tax software expects from you
Tax compliance software handles the computation reliably. Vertex, Avalara, Thomson Reuters ONESOURCE and Corptax maintain state rules, weightings, throwback provisions and the return preparation itself.
They expect factor data as an input. The receipts by state, payroll by state and property by state have to arrive already sourced, and the sourcing is the work. This is why apportionment consumes weeks in organisations that own excellent tax software, because the software starts after the hard part is finished.
Assembling factor data from the ledger, the customer master and payroll is exactly the cross system work ChatFin automates, as it does elsewhere in automated close management.
Building the data set once
The reason this is annual pain is that the assembly is discarded each year. Building it as a maintained data set changes the effort profile permanently.
Classify revenue by receipt type
Goods, services, intangibles and other, since sourcing rules differ by type. This classification is stable and only needs building once.
Attach a location concept to customers
Not just billing address but service locations, and where a customer is multistate, the basis for allocating between them.
Fix payroll work location
Distinguish work location from payroll registration and from home address. Remote work has made this materially harder and materially more important.
Build the property register by state
Owned property at value and rented property at the required multiple of annual rent, by location rather than by entity.
Refresh rather than rebuild
Once the concepts exist, each year is a data refresh and a review of changes, not a reconstruction.
Step three has become the fastest changing area. Distributed working means employees perform services in states where the organisation may have no other presence, which affects both the payroll factor and, potentially, nexus itself.
How ChatFin assembles the factors
ChatFin reads revenue detail from the ERP with the customer, contract and delivery information attached, rather than as a summarised revenue figure, which is what allows sourcing to be attempted at transaction level.
The autonomous reconciliation agent applies the sourcing classification you define by receipt type and customer, and the pattern recognition agent flags the receipts where sourcing is ambiguous instead of defaulting them silently. For the payroll factor it reads payroll and HR data to distinguish work location from registration, and for property it assembles the fixed asset and lease data by location. The conversational finance AI layer answers questions such as which customers are sourced on an allocation basis and what share of receipts that represents.
| Reconciliation agent | Applies your sourcing rules by receipt type at transaction level and assembles receipts by state |
| Document processing | Reads contracts and service records where the delivery location is not in the ledger |
| Analytics agent | Builds payroll by work location and property by state including rented property at the required multiple |
| Pattern recognition | Flags ambiguous receipts and quantifies the population sourced on an allocation basis |
| Governed write back | Prepares the factor schedules with the sourcing basis documented, for tax review |
The sourcing method remains a tax judgement made by your team. ChatFin applies it consistently at transaction level, documents what was applied where, and makes the ambiguous population explicit rather than absorbing it.
Reducing next year's effort now
The work that shortens next year's apportionment happens during the year, not during the compliance season.
Classify this year's revenue by receipt type
A one time exercise that makes every subsequent year's sourcing tractable.
Capture service location on new engagements
A single field at contract or order entry removes the largest ambiguity permanently.
Reconcile payroll work location
Compare payroll registration against actual work location for the distributed population. Expect surprises.
Quantify the ambiguous share
Measure what proportion of receipts is sourced on an allocation basis, and target the largest category for data improvement.
The second step is the highest leverage and the hardest organisationally, because it asks a commercial process to capture a tax data point. Framing it as a customer service location rather than a tax field usually gets it accepted.
The formula is published and the arithmetic is trivial. The expense is entirely in producing inputs the ledger was never designed to hold.
ChatFin
Frequently Asked Questions
Why is state apportionment difficult if the formula is published?
Because the inputs do not exist in the required shape. Receipts must be sourced to states based on where the customer received the benefit, and the ledger records a customer, an invoice and possibly a billing address rather than a delivery location. Payroll must be attributed to where services were performed, which for distributed workers differs from payroll registration. The formula is arithmetic, the sourcing is the work.
What is wrong with using billing address for receipts sourcing?
It is a convenient proxy and frequently identifies the wrong location. A billing address often belongs to a shared services centre or procurement office in a different state from where the service was actually received. For customers receiving a service across multiple locations, sourcing everything to a headquarters address distorts several states at once and is straightforward for an examiner to identify.
How should ambiguous receipts be sourced?
Classify by receipt type first, then apply a reasonable allocation basis where the benefit is genuinely received in several states, such as user counts or locations served. Document the basis once and apply it consistently across years, since inconsistency attracts more scrutiny than imperfection. Quantify the share of receipts sourced on an allocation basis so the exposure from the method is known rather than open ended.
Can ChatFin produce apportionment factor data?
ChatFin reads revenue at transaction level with customer, contract and delivery detail attached, applies the sourcing rules your tax team defines by receipt type, and assembles receipts by state. It builds the payroll factor from work location rather than registration, and the property factor from fixed asset and lease data by location. Ambiguous receipts are flagged and quantified rather than defaulted silently.
This article is general information for finance and accounting teams. It is not accounting, tax or legal advice. Confirm the treatment of your own facts with your auditors and advisers.
See ChatFin assemble your apportionment factors from source data.
ChatFin sources receipts at transaction level using the rules your tax team defines, builds payroll by actual work location, and assembles property by state including rented property.
Receipts that cannot be sourced precisely are flagged and quantified, so the method is documented and the exposure is known rather than absorbed.
Book a DemoBring a year of revenue detail and payroll data.
ChatFin will source receipts at transaction level under your rules, build the payroll and property factors, and quantify the ambiguous population.