Your CapEx Classification Agent Is Applying Accounting Policy. Can You Prove It?

A controller deploys an AI agent to classify incoming expenditures as capital or operating expense. The agent reads invoice metadata, checks useful life estimates, compares amounts against the company's capitalization threshold, and posts a classification with a short rationale. By month end it has processed hundreds of items. Software licenses go to the balance sheet. Routine maintenance goes to the income statement. A few items get flagged for reclassification when the agent finds a prior period entry that should have been OpEx.

When the external audit team arrives in Q1 2027, they do not ask whether the agent ran. They ask which capitalization policy it applied on March 14 when it classified a $250,000 software implementation as CapEx under ASC 350. They ask whether that policy matched what the audit committee approved. They ask whether a material misclassification would have reached a human reviewer before it hit the general ledger.

Most teams cannot answer those questions with evidence that survives scrutiny.

Why misclassification is an audit priority

CapEx versus OpEx is not a labeling exercise. It determines whether an expenditure increases reported assets or reduces reported earnings in the current period. Classifying OpEx as CapEx inflates the balance sheet and understates expenses. Earnings look better than they should. This is one of the most frequent financial statement audit findings and appears repeatedly in SEC enforcement actions involving revenue and expense manipulation.

The governing standards are ASC 350 for internal-use software and other intangibles, and ASC 360 for property, plant, and equipment. IFRS entities reference IAS 16 and IFRS 16 for leases. The specific rules vary by asset type, but the audit question is consistent: did the company apply its stated policy consistently, and can it demonstrate that for each material item?

The PCAOB tests capitalization controls directly during SOX audits. AS 2201, as amended for fiscal years beginning on or after December 15, 2026, requires evidence that automated controls operated effectively throughout the period. An AI agent making classification decisions at scale is an automated control. Application logs and spreadsheet summaries are not sufficient when the auditor needs to tie a specific March decision to the policy version the board approved in January.

The policy versioning problem

Company capitalization policies change. Thresholds move from $5,000 to $50,000. Software capitalization rules tighten after a restatement. A new subsidiary adopts a different materiality definition. Each change should produce a new policy record, not an edit to the old one.

When an agent classifies an expenditure, the audit record must capture the policy version in effect at that moment. Without version binding, an auditor comparing a September decision to the policy document the company hands over in February has no way to know whether the agent followed the rules that actually applied in September. Post-hoc reconciliation is reconstruction, not evidence.

Sigmodx stores policy versions in an append-only registry. When policy changes, a new version is inserted with threshold amounts, materiality limits, and effective date. Every classification decision records the policy version the agent applied. Period attestations include the policy version in effect for the attested window. An auditor verifying a SIGMODX-CAPEX verification string receives summary counts, category breakdown, total CapEx and OpEx values classified, and the policy version reference without accessing your ERP.

Material decisions need human oversight evidence

A $500 misclassification is noise. A $5 million misclassification is a material misstatement. SOX controls distinguish between immaterial volume and material items that affect what investors see.

Material classification decisions should not execute downstream accounting entries without human approval. The approval itself must be logged immutably: who reviewed, when, and whether they agreed with the agent's classification or escalated to the controller.

Sigmodx sets requires_human_approval automatically when is_material is true. It also flags potential misclassifications when an agent classifies an amount above the capitalization threshold as OpEx. Reviewer assessments feed reliability signals weighted toward material accuracy. An agent with strong overall agreement but poor material accuracy moves to LIMIT or BLOCK before it can misclassify another quarter-end accrual.

Reclassification is its own audit trail

Agents do not only classify new expenditures. They also correct prior periods. A software license capitalized in Q2 may need reclassification to OpEx when the company discovers the implementation did not meet ASC 350 criteria for capitalization. Each reclassification changes reported assets and may require a prior period adjustment.

Reclassify decisions require prior_classification and prior_period on the audit record. The attestation summary counts reclassified items separately from new CapEx and OpEx decisions. Auditors reviewing reclassification rates can identify systematic errors: an agent that reclassifies 15 percent of prior CapEx decisions may be correcting for a flawed training set or an outdated policy interpretation.

What the reliability signal measures

Five signals computed over a trailing thirty-day window drive ALLOW, LIMIT, and BLOCK state. Reviewer agreement rate measures how often human reviewers confirmed the agent's classification. Reclassification rate tracks how often the agent is correcting prior decisions. Escalation rate captures ambiguous items sent to senior accounting. Material accuracy rate applies only to material decisions and is weighted most heavily in BLOCK thresholds. Policy compliance rate checks whether decisions match threshold rules without requiring human review.

BLOCK triggers when reviewer agreement falls below 85 percent with at least ten reviews, or material accuracy falls below 90 percent with at least five material decisions. LIMIT applies at softer thresholds. Supervisors may override with a logged reason, but the override itself is part of the audit record.

Three questions for your controller

First: is every classification tied to a specific policy version, or does your agent apply whatever threshold is in a config file today? If the answer is the latter, you cannot prove March decisions followed January policy.

Second: do material classifications require logged human approval before posting, or does the agent write directly to the subledger? SOX expects evidence of review for items that matter.

Third: can an external auditor verify your period attestation without accessing your ERP or vendor data? If verification requires system access, you have a custody problem. The verification string model lets the auditor confirm record integrity from a hash alone.

Closing the loop

The team with a proper audit trail answers all three questions in an afternoon. Internal audit pulls the attestation, verifies the SIGMODX-CAPEX string, and samples material decisions against reviewer assessments. External audit does the same with the verification string you provide in the PBC package.

The team without that trail has a different experience. The agent ran for months. Classifications live in application tables that can be edited. Which policy applied on any given date is a matter of recollection. When the PCAOB asks about capitalization controls, the conversation takes weeks instead of hours.

CapEx classification is not harder to audit than invoice approval. It is harder to fake compliance after the fact. Policy versioning and materiality handling are the requirements that make this scenario distinct. Build the audit trail when you deploy the agent, not when the auditor asks for it.