# When Activity-Based Costing Can Improve Small Business Decisions

Activity-based costing can improve decisions when products, orders or customers consume support activities differently and a broad allocation rate hides those differences. It groups relevant overheads into activity pools, identifies what drives each activity and assigns costs according to the activity used. Start with a specific decision, not a desire to measure everything.

For a small business, the strongest case is often a mismatch between sales volume and operational effort. A large repeat order may need little administration, while many small customised orders create frequent setups, purchase orders, inspections and customer calls.

## Look for signs that a simple average misleads

Consider an illustrative Faridabad component manufacturer making a standard bracket and a customised bracket. Both use similar machine time per unit. The existing system allocates all support overhead by units produced, so each bracket receives the same overhead amount.

The production team reports that customised brackets require many more changeovers and first-piece inspections. Sales volume therefore does not explain all support work. The owner wants to know whether custom work needs a setup charge, a larger minimum batch or a revised price.

ICAI's activity-based costing material distinguishes unit-level, batch-level and other support activities. The practical implication is that the number of units alone may be a poor measure of the resources consumed by small, varied production runs.

## Build a small pilot around two activities

Suppose the manufacturer identifies these illustrative monthly pools:

| Activity pool | Cost | Total driver quantity | Driver rate |
|---|---:|---:|---:|
| Machine setup support | ₹1,20,000 | 40 setups | ₹3,000 per setup |
| Inspection support | ₹80,000 | 100 inspection hours | ₹800 per hour |

Standard brackets total 10,000 units, requiring 10 setups and 25 inspection hours. Custom brackets total 2,000 units, requiring 30 setups and 75 inspection hours. Standard work receives ₹30,000 setup cost and ₹20,000 inspection cost, or ₹50,000 overall.

Custom work receives ₹90,000 setup cost and ₹60,000 inspection cost, or ₹1,50,000 overall. Support cost is ₹5 per standard bracket and ₹75 per custom bracket. A uniform allocation of ₹2,00,000 over 12,000 units would assign only about ₹16.67 to each.

The pilot does not change total support spending. It changes the explanation of which work consumes it. That can materially alter a pricing or batch-size decision.

## Choose drivers that explain resource use

Setup count works when setups are reasonably comparable. If one takes 20 minutes and another takes four hours, setup time may be a better driver. Inspection hours can be more useful than inspection count when tests vary greatly in complexity.

Ask the people performing the activity what creates work. Then check the answer against records or a short observation period. An allocation base chosen solely because the data is convenient can reproduce the same distortion under a more sophisticated name.

Keep cost pools distinct. If supervisor time is included in setup support, remove that time from any other pool charging the same work. Reconcile the pilot's total assigned costs to the underlying expense list so that greater detail does not introduce double counting.

## Translate the finding into a decision

The custom bracket may still be commercially attractive. The owner could quote a separate setup charge, consolidate delivery schedules, offer a standardised design or set a minimum production quantity. These options address the activity causing cost rather than simply increasing every product price.

A customer analysis can use the same logic. Track order processing, special delivery and service calls for accounts where support demands differ sharply. A high-revenue customer can consume substantial resources, but allocated activity cost alone does not prove the account should be dropped.

Distinguish resources consumed from costs that can actually be avoided. Removing ten setups may free staff time without reducing this month's payroll. The benefit could be extra capacity or less overtime rather than an immediate cash saving.

## Know when the extra detail is unnecessary

A business with one standard product, similar orders and a small overhead pool may gain little from a complex activity system. A simple labour-hour or machine-hour rate can remain adequate where resource consumption is broadly uniform.

Data collection also has a cost. Staff should not spend hours coding trivial activities if the result cannot change a meaningful decision. Use broad, defensible pools first and refine only the areas where the pilot exposes a material difference.

Avoid using one unusually busy month as the permanent rate basis. Consider normal activity and explain unused resources separately where relevant. Otherwise, a temporary fall in orders can inflate driver rates and obscure the real capacity issue.

## How can the owner validate a new driver?

Take several recent orders and ask whether the proposed driver ranks their support effort sensibly. If the smallest custom order receives almost no setup cost despite requiring several changeovers, the driver is probably missing something. If similar orders receive sharply different costs, check the recording rules before trusting the comparison.

Reconcile the pilot with staff observations and total resources available. Recorded setup hours cannot sustainably exceed the team's available time without another explanation. A useful driver should support a reasonable physical story as well as an arithmetic allocation. That check makes the model easier to maintain and harder to manipulate for a preferred result.

## Run a focused review cycle

Choose one product family or customer segment and collect enough evidence to test the suspected distortion. Compare the pilot result with the existing allocation, explain the difference and identify one concrete policy change. Review the result after that change.

Activity-based costing earns its effort when it makes a specific choice clearer. Start where operational complexity differs most, keep the driver definitions understandable, and connect the calculation to pricing, batching or service design. A small, well-maintained model can be more useful than a detailed system whose numbers nobody trusts.

## Sources and references

- [ICAI: Activity Based Costing](https://resource.cdn.icai.org/74748bos60489-cp5.pdf)