Cloud Infrastructure
Accounting Standards

Framework

Cloud Infrastructure Accounting Standards Framework

Cloud Infrastructure Accounting Standards establishes six numbered principles that form the conceptual foundation for cloud and AI infrastructure cost governance.

Guidance

Infrastructure whose function is to serve customers or generate billable usage qualifies as COGS; development, testing, and internal administrative infrastructure qualifies as OpEx. The governing classification test is whether the workload exists to deliver the product to customers. Classification is determined by workload function, not by vendor, account structure, environment label, infrastructure type, or billing mechanism. Both variable costs that scale with usage and fixed costs required to sustain production delivery qualify as COGS when that functional relationship is established.

For workloads where the relationship to customer delivery is ambiguous or shared, proportional scaling with revenue drivers (API calls, active users, transactions) is the strongest available indicator of production function. Where revenue linkage is partial rather than direct (ie., infrastructure serving both paying customers and free-tier users, or inference workloads supporting both customer-facing inference and internal model evaluation), apply the test to the revenue-generating function only. Classify costs attributable to non-revenue functions as OpEx.

Allocate shared costs using a systematic and rational method (compute hours, storage consumption, or API calls) documented in your accounting policy. ASC 330-10-30-1 and IAS 2 §12 provide the allocation framework; ASC 606 and IAS 1 §27 provide the matching rationale linking cost recognition to the revenue period served. When the revenue-generating proportion cannot be measured reliably from consumption data, classify the full cost as COGS until tagging and monitoring are sufficient to support proportional allocation. Classifying a known shared workload as COGS understates gross margin rather than flattering it, which is the more conservative position for investor and board reporting. Establishing the measurement capability to support allocation should be a near-term priority.

All classifications under this standard use amortized cost as the measurement basis. Prepaid cloud capacity arrangements (ie., Reserved Instances, Committed Use Discounts, Savings Plans, and equivalent instruments) are recognized ratably over the commitment term, not in the purchase period. Recognizing the full prepayment at purchase distorts period costs and undermines the matching principle this standard enforces. On-demand charges require no adjustment; they accrue in the period consumed. All CIAS classifications apply this amortized cost basis.

Guidance

ASC 270-10-45-13, IAS 34, and COSO Principle 10 provide the conceptual foundation for cloud forecast governance as a formal control activity over financial reporting estimates.

Set variance targets of ±5% monthly and ±10% quarterly. Complete variance analysis within five business days of month-end. Require joint Finance-Engineering sign-off on forecast accuracy. Assign remediation owners to variances exceeding ±10%.

A complete variance explanation identifies four elements: (1) the specific service or workload that drove the variance; (2) the consumption change that caused it, expressed in measurable units such as instance hours, API calls, or storage volume; (3) whether the cause was a one-time event or a structural shift in consumption patterns; and (4) whether a classification review is warranted.

A corrective action plan is required for every variance exceeding ±10% and must contain three elements: (1) the named owner from both Finance and Engineering; (2) the specific action being taken; and (3) a resolution date not exceeding 30 days for operational remediation or one full reporting cycle for forecast model revisions.

Guidance

Finance owns cost classification, reporting, and policy documentation. Engineering owns resource consumption, tagging compliance, and advance notification of architectural changes that affect cost allocation. Both teams share responsibility for forecast accuracy through monthly variance reviews, with joint sign-off required on variance reports within five business days of month-end.

When variance reviews surface unresolved disputes, including disagreements about classification, consumption causation, or remediation ownership, escalate to the CFO within ten business days of month-end. The CFO holds final authority on classification disputes. Remediation plans for variances exceeding ±10% require named owners from both Finance and Engineering, a root cause determination, and a corrective action timeline. Unresolved breaches carrying into a second consecutive month are reported to the board as a governance exception.

A quarterly Cloud Governance Committee, chaired by the CFO or VP Finance, reviews tagging compliance, classification policy changes, and commitment approvals. This committee is the standing forum for cross-functional cloud cost decisions that fall outside the monthly variance cycle.

Guidance

Under GAAP and IFRS, cloud purchase commitments are executory contracts; they do not become balance sheet liabilities until services are delivered or payments fall due. This means a company can carry significant multi-year cloud obligations with no balance sheet representation and no required disclosure until triggered by materiality thresholds. In practice, most CFOs are not formally disclosing these obligations today. CIAS-4 addresses that gap.

Disclose commitments exceeding 12 months in duration that are material to the financial statements. Materiality is assessed relative to total operating expenses, gross margin impact, and the company's overall obligation profile, not solely as a percentage of cloud spend. This disclosure belongs in your annual financial statement footnotes as a commitment note, consistent with how lease obligations and other purchase commitments are presented. For internal governance, update the disclosure quarterly in board materials.

The Commitment Note: Three Required Elements

Under US GAAP, cloud commitments may require disclosure as purchase obligations not recognized on the balance sheet, including amounts committed by year and in aggregate (consistent with ASC 440-10-50-1). Under IFRS, IAS 37 §86 requires disclosure of commitments not recognized as liabilities (the nature, timing, and amount of those obligations) when they represent material future cash outflows.

Guidance

Apply allocation methods and classification rules consistently period-over-period. The 50% production usage threshold is the default trigger for full COGS classification under this standard: workloads below this threshold default to OpEx until the threshold is crossed for two consecutive months.

Sub-threshold workloads (those with production usage between 20–49%) may be partially allocated between COGS and OpEx when supported by reliable consumption data (compute hours, API calls, or storage metrics) and documented in the accounting policy. Partial allocation requires Controller approval and must be applied consistently period-over-period. It cannot be used selectively to manage margin in a given period. Workloads below 20% production usage are classified as OpEx without allocation.

Flag workloads exceeding 35% production usage for monthly monitoring. When a workload's production usage crosses the 50% threshold for two consecutive months, reclassify it (moving it from OpEx to COGS, or from COGS to OpEx) effective the first day of the month following the second consecutive month of threshold crossing. Apply the new classification going forward only; do not restate prior periods. Document the reclassification with Finance and Engineering approval, noting the workload, the triggering usage data, and the effective date. Disclose any reclassification that exceeds 5% of prior period cloud costs in the next variance review.

Disclose any reclassification that exceeds 5% of prior period cloud costs in the next variance review. Do not use reclassification to manage margin in a given period.

Guidance

Under US GAAP, ASU 2018-15 (amending ASC 350-40) permits capitalization of eligible implementation-stage costs for cloud hosting arrangements, including configuration and custom coding, with amortization over the hosting arrangement term. The determination follows a three-stage project framework.

• Preliminary-stage costs (evaluating alternatives, selecting a vendor, determining feasibility) are expensed as incurred under both US GAAP and IFRS. No exceptions apply.
• Application development-stage costs (configuration, custom coding, and integration work that produces functionality the entity will use) may be capitalized under US GAAP when the project has passed the preliminary stage and management has authorized and committed to the implementation. Capitalization ceases when the software is substantially complete and ready for its intended use.
• Post-implementation-stage costs (training, maintenance, and minor modifications) are expensed as incurred under both regimes.

LLM and other neural network training and fine-tuning costs are expensed as incurred under both US GAAP and IFRS. In most cases, the underlying model artifacts will not meet the ownership and control criteria required for capitalization under ASC 350-40 or IAS 38. The narrow exception, where development produces separately owned and controlled software artifacts, requires documented evidence of ownership, control, and the applicable project-stage determination before capitalization is supported.

Amortization of capitalized implementation costs runs over the term of the hosting arrangement, not the useful life of the underlying software. Classify amortization expense using the same functional classification test as other cloud costs: amortization attributable to production systems is COGS; amortization attributable to internal systems is OpEx. Do not default all amortization to OpEx; classification follows function, consistent with CIAS-1.

Under IFRS, the IFRS Interpretations Committee (April 2021 Agenda Decision) concluded that configuration and customization costs in cloud arrangements are expensed as services are received, because the customer does not control the resulting asset. The only exception applies where the arrangement produces separately controlled code or software, which is rare in practice and requires the same ownership and control analysis as US GAAP.

Implementation

Cloud Cost Classification Framework (COGS vs OpEx)

Proper classification determines gross margin accuracy. CIAS-1 (Classification) provides the conceptual foundation.

The governing test is whether the workload exists to deliver the product to customers. For workloads where that relationship is clear, the functional purpose is sufficient. For workloads where the relationship to customer delivery is ambiguous or shared, proportional scaling with revenue drivers is the strongest available indicator of production function.

GAAP/IFRS Divergence: Capitalization Treatment

US GAAP (ASU 2018-15, amending ASC 350-40) permits capitalization of certain implementation-stage costs for cloud hosting arrangements (including configuration and custom coding) and amortization over the hosting arrangement term.

IFRS takes the opposite position. The IFRS Interpretations Committee (April 2021 Agenda Decision) concluded that configuration and customization costs in cloud arrangements are expensed as the services are received, because they do not create an asset the customer controls. The only exception: costs that produce separately controlled code or software (rare in practice) may qualify for capitalization under IAS 38.

Non-Usage Charge Types: Classification Treatment

Cloud billing includes charge categories beyond usage consumption. Each requires a defined treatment under CIAS to prevent misclassification at month-end.

Shared Infrastructure Allocation

When infrastructure supports multiple products, allocate costs using compute hours, storage consumption, or API calls. Document the allocation methodology in your accounting policy per CIAS-5. Review the methodology quarterly for continued reasonableness.

Mixed-Use Infrastructure

The most common classification dispute involves infrastructure that simultaneously serves customer-facing and internal functions. A data warehouse is the typical example: the same cluster may power both customer-facing analytics (COGS) and internal business intelligence reporting (OpEx). Apply the classification test by function, not by resource. Measure the proportion of query volume, compute hours, or storage consumption attributable to each function over a representative trailing period of at least 60 days. Allocate costs in that proportion, document the methodology, and apply it consistently per CIAS-5. If reliable consumption data is unavailable to support a split, classify the entire resource as COGS until tagging and monitoring are sufficient to support proportional allocation. Classifying a known shared resource as COGS understates gross margin, which is the more conservative position for investor and board reporting. Establishing the measurement capability to support allocation should be a near-term priority.

AI Infrastructure Classification

AI infrastructure costs follow the same functional classification test as other cloud costs, applied by workload function rather than by resource type.

Inference costs for a deployed model serving customer requests scale directly with usage and qualify as COGS. Training costs incurred to develop or improve a model prior to deployment are internal R&D expenditures and qualify as OpEx. Fine-tuning and continuous learning workloads that run post-deployment require evaluation by function: fine-tuning runs that improve the live production model's accuracy are a production support cost and may be classified as COGS; exploratory fine-tuning for future model versions is OpEx.

Model monitoring and evaluation costs (including automated test suites and human review pipelines) are OpEx when they serve internal quality assurance, and COGS when they are a contractual or operational requirement of serving customers, ie., safety classifiers running on every customer request.

Training costs are expensed as incurred under both US GAAP and IFRS in most circumstances. The ownership and control criteria required for capitalization under ASC 350-40 are difficult to meet for neural network training in practice. See CIAS-6 for the full capitalization framework.

Where a single GPU cluster serves multiple workload types (training, inference, and evaluation), allocate costs by GPU-hours consumed per workload type over a trailing 60-day period per the Allocation Documentation Standard above.

Allocation Documentation Standard

Documenting an allocation methodology means more than naming the metric. A CIAS-compliant allocation policy records four elements: (1) the allocation key selected (compute hours, API calls, or storage consumption); (2) the data source used to measure it (e.g., cloud provider cost and usage report, APM tooling, infrastructure monitoring platform); (3) the measurement period applied (trailing 60-day minimum per this standard); and (4) the approver, with Controller sign-off required for initial adoption and any subsequent methodology change. These four elements constitute the documented methodology referenced in CIAS-1 policy language and required for CIAS-5 consistency enforcement. An allocation policy that cannot satisfy all four elements does not meet the standard. The conservative posture is to classify the affected workload as COGS in full until adequate documentation is in place to support proportional allocation.

Reclassification Events

A workload's initial classification is not permanent. When a workload's production usage changes materially (ie., when a development environment moves into production, or when a production workload is decommissioned and repurposed for internal use), reclassification is required.

CIAS-5 governs the mechanics: reclassification applies prospectively from the first day of the month following two consecutive months of threshold crossing. Prior periods are not restated. The reclassification decision requires Finance and Engineering approval and must be documented with the triggering usage data and effective date.

Reclassification events must be disclosed in the next variance review if the reclassified cost exceeds 5% of prior period cloud costs. A reclassification of that magnitude affects gross margin comparability and warrants explanation to anyone reviewing trend data.

Do not use reclassification to manage margin in a given period. A reclassification made outside the two-consecutive-month threshold process, without documented triggering data and dual approval, is a classification change that requires accounting policy disclosure under ASC 250-10-45-2 / IAS 8 §14.

Implementation

Commitments & Disclosure Standards

Multi-year cloud commitments represent significant future cash obligations that require formal governance and disclosure. CIAS-4 establishes the disclosure framework.

Disclosure Requirements

• Commitments exceeding 12 months in duration that are material to the financial statements require formal disclosure.
• Materiality is assessed relative to total operating expenses, gross margin impact, and the company's overall obligation profile.
• Disclosures must include the three elements defined in the commitment note guidance below.

Commitment Note Example: Obligation Schedule (Element 1 of 3)

The following example illustrates Elements 1 and 2 of the commitment note: the obligation schedule and utilization forecast presented together. Element 3 (sensitivity analysis) builds on this schedule and is presented to the board quarterly.

Appendix

CIAS Framework Principles & GAAP/IFRS Alignment

CIAS Framework Principles

Additional GAAP/IFRS Alignment