In companies where multiple departments use LLM APIs, usage levels vary from department to department, creating a need for mechanisms that allocate budgets fairly while maintaining cost transparency. It is not uncommon for a single department to see its API usage costs surge sharply, straining the entire company's budget by the end of the quarter. Conversely, there are also cases where a department's actual usage goes unmonitored, leaving managers struggling to explain the situation when drafting the following year's budget. This article organizes procedures that practitioners can implement immediately, covering everything from the concept of departmental cost allocation and chargeback method design to setting usage caps and monthly/quarterly monitoring systems. As a guide for finance/planning departments and IT administrators to advance company-wide cost optimization while preventing feelings of unfairness between departments, we will cover the allocation rules and chargeback design sections in particular detail with concrete calculation examples, while touching on the monitoring system briefly, focusing on key operational points.

Quote drafts generated by the sales department, code completion tested by the development department, copy proposals generated by the marketing department—even with the same LLM API, usage patterns and call frequency differ completely by department. If this difference is left unaddressed, simply staring at a report stating "this month's API usage cost was three times higher than expected" won't reveal where action needs to be taken.

Grasping departmental usage patterns numerically and allocating costs according to that reality—this is the starting point of LLM API budget management. In environments where multiple departments share the same API key or platform, it's easy for who used how much to become unclear, resulting in cases where the "department that overused" and the "department that barely used it" end up bearing the same cost burden. First visualizing usage volume, and then establishing a system for setting budget allocations by department, becomes the starting point for company-wide cost optimization.

Challenges in Departmental Cost Management for LLM API Usage

When departments are limited to a few teams, usage status can be grasped through coordination between staff members, but when multiple departments use LLM APIs in parallel, actual usage becomes harder to see, making a budget management system essential. When each department issues its own API keys and proceeds with usage for different purposes—the sales department for customer service automation, the development department for code generation support, the planning department for document creation assistance—the correspondence between usage purpose and usage volume tends to become difficult to grasp across the organization as a whole.

Since OpenAI and Azure OpenAI billing is finalized on a monthly cycle, cases arise where unexpected billing amounts are discovered at month-end if departmental usage isn't visualized in advance. The fact that unit prices vary significantly depending on model selection is also easily overlooked. When departments that regularly use high-performance models coexist with departments for which lightweight models suffice, the cost difference widens even for the same number of tokens.

If the distinction between departments with high usage efficiency and those with low efficiency is left unclear, then even when budget overruns occur, it becomes impossible to trace where responsibility lies. A system that continuously records departmental usage patterns and can detect early signs of overruns is the prerequisite for company-wide cost optimization.

A departmental budget is akin to petty cash divided among departments from a single wallet called the company-wide budget. It has a structure in which an upper limit usable by each department is allocated within the range that does not exceed the company-wide framework.

The general flow is that the finance department finalizes the company-wide budget annually or quarterly based on the business plan and previous year's results, and then allocates it top-down to each department from there—but bottom-up adjustments that review the company-wide budget by aggregating each department's actual usage status are also essential. Top-down figures and bottom-up actuals are not independent of each other; consistency between them must be maintained at all times.

Consider a case where the marketing department sharply increases its usage volume due to building an AI chatbot for a campaign. Should that increase be absorbed from other departments' surplus allocations, or should the company-wide budget itself be adjusted? Without deciding on this judgment criterion in advance, negotiations tend to arise between departments along the lines of "why is our allocation being cut?" Allocation rules are worth documenting before trouble occurs.

If the linkage between the company-wide budget and departmental allocation remains loose, even introducing the chargeback methods and usage cap settings discussed later will have diminished effectiveness. This is a foundational area where the details should be worked out carefully.

When multiple departments share an LLM API, there are many situations where staff members struggle over how to distribute costs. Simple equal division tends to generate dissatisfaction between departments with high usage and those with low usage, while relying solely on strict usage-based allocation tends to leave the treatment of fixed cost portions, such as shared infrastructure maintenance costs, ambiguous. Broadly speaking, there are three approaches to allocation: usage-based allocation based on actual token consumption or API call counts, separation of fixed costs and variable costs that distinguishes infrastructure maintenance expenses from actual usage, and a method that determines allocation after visualizing each department's actual usage patterns using log management tools. Among these, usage-based allocation is an unavoidable foundation as the starting point for operations, and will be covered in the most detail in the next section as well. The separation of fixed and variable costs and the use of visualization tools are often positioned as elements to be established later, depending on the organization's governance maturity.

Usage-based allocation assigns costs according to each department's actual consumption.

The first decision to make is whether to use token count or API call count as the basis. When using token count as the basis, since many models have different unit prices for input tokens and output tokens, failing to tally the two separately will cause the burden allocated across departments to deviate from reality. Departments that frequently handle long-text summarization tasks tend to have a higher proportion of output tokens, and allocating costs based solely on call count risks underestimating their actual usage.

The method of using API call count as the basis is simple to tally, but it lacks fairness when the token volume per call varies significantly across departments. This is because a department that makes frequent short queries and a department that infrequently generates long text will have vastly different costs despite the same call count.

In practice, a method tends to take root where department-tagged logs are obtained from the usage measurement APIs provided by OpenAI and Anthropic, and monthly aggregation is performed on a token-count basis. By attaching project IDs or tags to the logs in advance, the allocation work becomes easier to automate.

The basic decision axis is to treat cases where capacity is reserved on a time-unit basis, such as with Provisioned Throughput, as fixed costs, and cases centered on pay-as-you-go token usage fees as variable costs. Azure OpenAI offers two billing formats, Pay-As-You-Go and PTU (Provisioned Throughput Units); since PTU is billed on a time-unit basis, a fixed amount is incurred regardless of monthly usage volume. Similarly, OpenAI's Scale Tier involves purchasing input and output token units on a daily prepaid basis, with a minimum purchase period of 30 days assumed, giving it a nature that is effectively close to a fixed cost.

On the other hand, usage fees charged on a pay-as-you-go basis for regular API calls constitute a variable cost that fluctuates according to each department's token usage. In practical separation work, the first step is to distinguish whether a contract is one that reserves dedicated throughput on a per-contract basis, or one that is purely pay-as-you-go. For the former, it is appropriate to allocate to each department's budget frame in advance, and for the latter, to allocate monthly based on actual usage. For companies using multiple contract formats concurrently, first allocating the fixed-cost portion to all departments as a shared cost, and then allocating only the remaining variable cost on a usage basis, makes the cost structure easier to grasp.

Department-level allocation has no meaning if the granularity of the underlying data is coarse, even if the calculation formula itself is correct. The prerequisite is a system for continuously collecting and visualizing usage logs.

OpenAI's Usage API and Costs endpoint, AWS's Cost and Usage Report (output to S3), and Azure's Cost Management export (written to storage on a daily, weekly, or monthly basis)—all of the major providers are equipped with mechanisms that allow department tags or project IDs to be attached. This point becomes the key in practical operations.

If tagging is coarse, usage of API keys shared across multiple departments becomes mixed together, and the allocation calculation itself stops functioning. It is desirable to design tags across three tiers—department, project, and purpose of use—and establish a system where logs are aggregated into a data warehouse and can be checked via a monthly dashboard.

How should allocation data be converted into "billing" so that departments can accept and manage their budgets with confidence? The chargeback method is a mechanism for reflecting allocation results in actual departmental budgets, and it requires designing both the method selection and the unit price setting. Unit price setting in particular tends to become entangled with power dynamics between departments, and in settings where departments with differing usage volumes and negotiating power—such as sales departments and engineering departments—sit at the same table, a sense of unfairness can erupt all at once depending on how the decision is made. The following H3 sections delve into representative operational patterns and approaches to unit price determination.

Depending on how fine-grained the cost allocation is made, chargeback methods broadly divide into three patterns. Under the FinOps Foundation's definition, the method of directly assigning actual costs to each department's P&L is called chargeback, which is clearly distinguished from showback, where costs are only displayed while remaining under centralized management. This difference is similar to the distinction between actually collecting money in a bill-splitting arrangement versus merely sharing the receipt for viewing.

The most fundamental approach is the actual-cost allocation type, which converts each department's token count or API call count directly into cost and bills accordingly. While this most accurately reflects actual usage, departments with higher usage bear a greater burden, which tends to generate dissatisfaction regarding the balance between business contribution and burden. For example, a department that intensively uses a company-wide shared FAQ response platform tends to have an overwhelmingly higher call count than other departments, and under simple volume-based splitting, this structure can easily lead directly to complaints of "the more you use it, the more you lose."

The fixed-amount allocation type is a method of distributing a predetermined amount according to department size or seat count; while this offers high budget predictability, there are cases where the gap from actual usage becomes large.

The hybrid type fixes the base fee portion while allocating only the excess portion on a usage basis. In practice, many companies follow a sequence of first advancing visualization through showback, then transitioning to chargeback once inter-departmental consensus has been reached, and this transition process itself is often a more important consideration than the choice of method.

When a single model is used, the basic policy is to reflect the actual cost directly in the unit price; when multiple models are used together, the unit price is calculated using a weighted average.

For example, in departments that use multiple LLM models concurrently, a weighted average unit price is calculated according to each model's usage ratio, and the billing amount is computed per department (the input/output token unit prices for each model are reference values at the time of writing, and the actual rates must be confirmed against the provider's latest price list). For departments that use only a single model, the official pricing of that model can be adopted directly as the allocation unit price, simplifying the calculation.

When using prepaid contracts such as Scale Tier or Provisioned Throughput Units (PTU), the basis should be the contract unit price (hourly or daily billing) rather than actual consumption. In this case, a two-tier design combining contract unit price and overage charges—such as adding on-demand rates for departments that exceed the contracted allocation—is effective.

Some companies add indirect costs, such as the operational expenses of monitoring tools and the labor costs of billing processing, to the unit price at a fixed ratio, in addition to direct API costs. Under the FinOps Foundation's definition as well, chargeback is a mechanism for allocating costs to the P&L of the department where the expense originated, and transparency in unit price setting determines its reliability. Reviewing unit prices periodically, in line with model pricing revisions and changes in usage ratios, makes operations easier to manage.

The usage cap is the last line of defense against budget overruns by department. By clarifying the decision criteria and establishing response rules for overages in advance, confusion such as emergency shutdowns can be avoided. The next section provides a concrete explanation of the approach to setting caps and the operational rules involved.

Many people in charge may wonder whether the same usage cap should be applied uniformly across all departments, or whether caps should differ by department.

Usage caps that are determined mechanically based solely on department size tend to diverge from actual conditions. As decision criteria, it is necessary to consider a combination of department headcount along with business contribution (impact on revenue and productivity) and LLM utilization priority (strategic importance).

• Department size: the baseline figure for number of users and request frequency
• Business contribution: whether the department's LLM utilization directly affects revenue or the quality of customer service
• Priority: weighting differs depending on whether it is a new project or proof-of-concept stage versus routine operations

For example, when a customer support department automates first-line response using an AI chatbot, its usage volume tends to be higher than that of a sales department. In this case, incorporating outcome metrics such as number of cases handled and resolution rate into the cap calculation—rather than a simple headcount ratio—brings the figure closer to actual conditions.

On the other hand, for departments at the PoC (proof of concept) stage, since outcomes are not yet confirmed, a practical approach is to set a looser, time-limited cap and revisit it after full-scale implementation. For low-priority routine operations, it is also worth considering gradually lowering the cap based on monthly usage results.

Decision criteria: How far usage should be automatically halted upon reaching the cap depends on whether business continuity or cost control is prioritized.

Even if a usage cap is set, if the response to overages is ambiguous, confusion arises on the ground, and as a result, the cap itself ceases to function. It is important to establish staged rules in advance.

• Send an alert notification to the responsible department and the management department upon reaching 80%
• Temporarily suspend new requests upon reaching 100%, requiring the approving authority's judgment
• Provide a temporary cap relaxation allowance via advance application for departments where the impact of a business halt would be significant

If temporary suspension is applied strictly, this can cause problems in departments directly tied to customer service or critical business processes. Conversely, if relaxation is granted too readily, the effectiveness of the cap itself is undermined. Therefore, whether to grant relaxation should be judged based on "degree of business impact" and "legitimacy of the reason for the overage," with the approval flow and responsible party clarified in advance so that operations do not become inconsistent.

For departments where overages recur repeatedly, rather than simply raising the cap, it is worth considering, alongside this, a review of search optimization and prompt design—such as described in What is Adaptive RAG? How to Balance Cost and Accuracy with Query-Driven Dynamic Retrieval—which can lead to a fundamental improvement in usage efficiency. Cap management should be positioned not merely as a restriction, but as a mechanism to promote optimization of usage by the department.

If usage volume is within expectations, the current allocation should be maintained; if it exceeds expectations, a decision on cap revision or reallocation becomes necessary. Without a continuous monitoring system, chargeback figures risk losing their reliability. Next, we explain how to establish, at a practical level, the visualization of usage status through reporting frequency and analysis methods.

In monthly reporting, the starting point is to consolidate token usage by department, API call counts, chargeback amounts, and month-over-month change rates into a single dashboard, creating a situation where the finance department and each department head can discuss the same figures. Major providers such as OpenAI and Azure OpenAI offer Usage APIs and cost export features, and by using daily or monthly exports to S3 or other storage, the reconciliation work against invoices can be shifted from manual effort to automation.

Quarterly reporting requires a different perspective. While the primary purpose of monthly reporting is anomaly detection and early identification of budget overruns, quarterly reporting compares usage efficiency by department (cost relative to deliverables or completed tasks) and uses this as the basis for the next quarter's budget allocation and limit reviews. It is useful to have a decision framework where departments with stable usage often only need monthly checks, while departments in new projects or verification phases, where usage tends to fluctuate significantly, warrant monitoring at a frequency closer to weekly even within the monthly cycle.

Additionally, for departments with a mix of fixed costs (reservation-based contracts such as Provisioned Throughput Units) and variable costs, a practical point for cost optimization is to cross-check contract renewal timing against actual usage each quarter and adjust for any excess or shortfall in reserved capacity.

In the operation of departmental cost allocation, unexpected questions and adjustments tend to arise. Here, we briefly answer three questions commonly raised in practice: resolving perceptions of unfairness, responding to unexpected increases in usage, and designing allocation when multiple APIs are used together.

Decision framework: Distinguish whether the source of the perceived unfairness lies in the allocation method or in the actual usage patterns.

Usage-based allocation may appear fair, but since task complexity and token consumption vary greatly by department, comparing based solely on call counts can lead to misunderstandings. For example, a department centered on summarization tasks and a department involving long-form generation or multi-step reasoning will show differences in token consumption even with the same number of calls. In such cases, re-allocating based on input/output token counts rather than call counts often resolves the sense of unfairness.

On the other hand, if there is no issue with the allocation method itself and a department simply continues to have high usage, it is more effective to review that department's usage purpose and priorities with stakeholders rather than revisit the chargeback unit price. If it is a high-value business initiative, this can lead to renegotiating budget allocation; if not, it can lead to reviewing usage limits or considering alternatives (such as local LLMs or lightweight model operation via PEFT).

In adjustment discussions, it is essential that the finance/planning department, IT administrators, and each department head review the same usage data together. Changing allocations based on intuition while the data granularity remains coarse tends to provoke similar complaints from other departments in the next quarter, so it is advisable to record the change history of the allocation logic and maintain transparency in the next monthly report.

The basic policy is to absorb temporary, sudden usage spikes using a reserve budget, and to address sustained increases in usage through a review of the quarterly budget. Projects in the PoC (proof of concept) stage tend to have difficulty estimating token consumption in advance, making it more likely that usage limits will be exceeded beyond expectations.

While the initial instinct may be to immediately bill the full excess amount to the department in question, in practice, examining the reasons for the overage and covering part of it from the company-wide reserve budget tends to prevent departments from becoming overly cautious and discourages hesitation toward experimenting with new technology. In particular, for usage aimed at verification, it is necessary to treat even failures as valuable outcome information.

Operationally, setting aside a fixed percentage of the company-wide budget as a "variable allowance" and establishing a mechanism for the finance/planning department to grant after-the-fact approval allows for flexible handling. For departments where overages occur repeatedly, this should be treated as an opportunity to reconsider the allocation rules or the design of usage limits themselves. If one-off exception handling is not distinguished from structural budget shortfalls, similar confusion will continue into subsequent periods; therefore, it is advisable to build in a process that records the cause classification when an overage occurs (temporary verification versus sustained demand increase) and reflects this in the next budget allocation.

When using multiple LLM APIs together, since billing units and pricing structures differ by provider, allocation rules need to be aligned to a common metric. Token counts and API call counts have different unit prices across vendors, which becomes a practical obstacle since comparing them directly tends to create disparities in the perceived burden between departments.

As a countermeasure, it is effective to first convert each vendor's usage fees into a common internal unit (such as an internally defined "standard processing unit"), and then use the converted values as the basis for departmental allocation. When fixing primary vendors by use case, it becomes easier to manage by separating allocation rules by use-case category (e.g., summarization, code generation, high-precision reasoning).

On the other hand, while a department is still independently comparing and evaluating multiple vendors, it is more realistic to prioritize allocation by use case or project over allocation by vendor, and to proceed with standardizing unit prices only after vendor selection has been finalized. For configurations that combine local LLMs or SLMs for some tasks, it is also worth reconsidering the allocation policy alongside options for reducing dependency on cloud APIs, such as those introduced in Local LLM/SLM Adoption Comparison. In any case, it is important that the conversion criteria be centrally managed by the finance/planning department to prevent inconsistent interpretation among departments.