A general AI system can recognize that an invoice appears to relate to software.
It does not automatically understand whether that software supports internal operations or customer delivery, which entity incurred the expense, when the treatment changed, which evidence controls the classification, or who may approve an exception.
Those answers come from organizational context.
A finance agent needs two maps: how the organization classifies activity and how the organization assigns decision rights.
Map one: Financial context
The financial-context map includes the chart of accounts, entity structure, departments, cost centers, products, customers, projects, reporting treatment, materiality thresholds, policy dates, historical decisions, and permitted exceptions.
The chart of accounts is part of this map, but not all of it. The system may need to understand why a classification applies and when it stopped applying.
Map two: Decision authority
The authority map answers who owns the policy, who supplies operational context, who may recommend a treatment, who approves it, who may override the default, who executes the action, and who resolves disagreement.
Technical permission and business authority are not the same thing. A person or agent may be able to update a record without being authorized to make the underlying accounting decision.
Context has a timeline
Consider a synthetic vendor whose service was historically treated as internal software expense. Beginning in a later period, part of the service directly supports a customer-facing product.
A system relying only on historical frequency may repeat the old treatment. A context-aware system needs the effective date, policy owner, usage evidence, approved treatment, and exception rules.
| Context field | Example value |
|---|---|
| Prior treatment | Software expense |
| Current treatment | Cost of revenue when linked to customer delivery |
| Effective date | Defined policy date |
| Policy owner | Controller |
| Operational owner | Engineering operations |
| Required evidence | Approved policy and usage report |
| Exception | Mixed use or missing evidence |
Retrieval is not governance
Connecting an agent to contracts, policies, prior transactions, and internal messages can improve context. It can also introduce conflicts.
- What if the contract and operational tracker disagree?
- What if an old message contradicts current policy?
- What if the most frequently retrieved example is obsolete?
- What if the correct source is applied to the wrong period?
- What if confidential information enters an unauthorized context?
Retrieval supplies information. Governance determines which information is authoritative.
The decision packet
| Field | Purpose |
|---|---|
| Proposed treatment | States the recommendation |
| Applicable period | Prevents obsolete policy use |
| Authoritative source | Identifies controlling evidence |
| Supporting context | Explains relevant operational facts |
| Conflicting evidence | Makes disagreement visible |
| Applied rules | Shows deterministic checks |
| Uncertainty | Identifies what remains unresolved |
| Required approver | Routes authority correctly |
| Permitted action | Limits what the system may do |
| Audit identifier | Connects the decision to its history |
The agent’s job is not to sound confident. It is to assemble the strongest available decision packet and recognize when that packet is incomplete.
What leaders should ask
- Can the agent identify the correct period?
- Does it know which source controls each field?
- Can it recognize superseded policies?
- Can it surface contradictory evidence?
- Does it distinguish recommendation from approval?
- Can it route the decision to the correct authority?
- Can it explain which rule permitted execution?
- Can the organization reproduce the decision later?
The strongest finance agent may be the system that knows which questions it is not authorized to answer.