---
type: idea
title: Accounting Context Runtime for Vendor Spend
created: 2026-06-21
status: seed
origin_sources:
  - "Conversation with Codex on special-purpose accounting-agent runtimes"
related_auto: []
used_in: []
---

# Accounting Context Runtime for Vendor Spend

## One-line thesis

The GL should be the compiled output of reviewed commercial context, not the place accountants reconstruct context after the fact.

## Product promise

Close starts with the accounting cases already prepared.

## Category

**Market-facing category:** always-on close preparation for vendor spend.

**Internal architecture category:** accounting context runtime for controllership.

Avoid leading with "AI accounting agent." That framing sounds risky, generic, and too close to autonomous posting. The better framing is a controlled preparation layer that turns commercial context into review-ready accounting cases.

## Founding insight

Accounting teams often close the books by reconstructing context under deadline. Contracts, POs, invoices, approvals, prior schedules, and policy decisions live across systems and people. The GL contains the compiled aftermath, but not the commercial context that explains why something should be accrued, prepaid, expensed, or ignored.

The product reimagines the GL as a downstream artifact. Accounting work starts from commercial context, moves through reviewable accounting cases, produces prepared schedules, and only then compiles into GL-facing outputs.

```text
Commercial context
-> Accounting case
-> Approved treatment
-> Prepared schedule
-> Draft JE / recon support / workpaper packet
-> GL
```

## First user

The first user is an accounting manager responsible for accruals, prepaids, and close readiness.

This person is asking:

- Did we accrue what we should have accrued?
- Did we miss any vendor obligations?
- Should this invoice be prepaid or expensed?
- Did a renewal change an existing schedule?
- Are our prepaid balances still supported?
- Are there large invoices without treatment?
- Are there contracts or POs with no invoice yet?
- Are there invoices with no contract or approval support?
- Is close going to be clean?

The product should make this user feel prepared before close begins.

## Enemy

The enemy is broken context flow between business activity and accounting treatment.

More specifically: accounting teams receive fragmented artifacts after the fact. A contract is in one place, a PO in another, an invoice in AP, an approval in email, prior treatment in a spreadsheet, and the GL entry somewhere else. The accountant's work becomes rebuilding context during close.

The product exists to move that work earlier.

```text
Today:
find issues during close
-> chase evidence
-> rebuild context
-> decide treatment
-> build schedule / JE

Target state:
runtime watches context continuously
-> prepares cases before close
-> accounting manager reviews exceptions
-> approved cases compile into artifacts
```

## V1 wedge

Vendor spend close preparation for accruals and prepaids.

V1 should focus on buy-side commercial context:

- vendor contracts
- renewals and amendments
- invoices
- POs
- billing schedules
- prior schedules and workpapers
- approval evidence
- company policy notes

Do not start with full customer contract revenue recognition. The same framework can eventually support sell-side contracts, but vendor spend is more bounded and more believable as the first controllership wedge.

## Main object

The user-facing object is an **Accounting Case**.

Internally, the runtime may reason in accounting assertions, evidence, treatments, and compiled artifacts. But the accounting manager should not live inside an assertion graph. They should see reviewable cases.

An accounting case answers:

- Why does this case exist?
- What commercial context triggered it?
- What accounting question does it raise?
- What evidence supports the proposed treatment?
- What prior treatment exists?
- What schedule or entry may be needed?
- What is missing or uncertain?
- What action does the accounting manager need to take?

Example case:

```text
Datadog renewal received.
Proposed treatment: prepaid software asset amortized over 12 months.
Evidence: renewal contract, invoice, prior-year schedule.
Missing: department approval.
Compiled artifact: draft prepaid schedule and monthly JE lines.
Status: Ready for Review.
```

## V1 case triggers

The runtime should create an accounting case when new or changed vendor commercial context raises an accrual or prepaid question.

Initial triggers:

- new vendor contract
- renewal or amendment
- new invoice
- open PO
- expected invoice missing near close
- invoice received without matching PO or contract
- material change from prior vendor treatment

Accounting question by trigger:

```text
New vendor contract
-> Does this create a prepaid, accrual, or recurring expense treatment?

Renewal / amendment
-> Does the term, amount, or treatment schedule need to change?

New invoice
-> Should this be expensed now, prepaid over time, accrued against prior service, or matched to an existing PO/contract?

Open PO
-> Has the service been received or obligation incurred, even if no invoice has arrived?

Expected invoice missing near close
-> Do we need an accrual?

Invoice without PO/contract
-> Is evidence missing, or is this ordinary low-risk spend?

Material change from prior treatment
-> Is this a real business change or a coding/treatment anomaly?
```

## Accounting Inbox

V1 does not need a NetSuite connector. The cleaner first surface is an **Accounting Inbox**.

The Accounting Inbox is where vendor commercial context lands. It can accept messy real-world artifacts, then the runtime converts them into structured context and cases.

Accepted inputs:

- PDF contracts, invoices, renewals, and POs
- XLSX or CSV schedules and exports
- forwarded emails with attachments
- policy notes
- approval notes
- prior workpapers

Minimum required context to prepare a useful case:

- vendor name
- amount or estimate basis
- service period or renewal term, if applicable
- close period
- source evidence

If required fields are missing, the runtime should still create a case when appropriate, but mark it **Needs Evidence**.

## Close setup

The accounting manager manually configures close setup in v1.

Required setup:

- active close period
- period start and end
- close deadline
- prepaid threshold
- accrual threshold
- materiality threshold
- company policy notes
- optional chart of accounts upload

Manual setup is acceptable because it lowers integration complexity and keeps the prototype focused on case preparation.

## Runtime loop

The always-on loop should be simple:

```text
1. Watch Accounting Inbox for new artifacts.
2. Classify artifact type.
3. Link artifact to vendor, prior schedules, prior cases, and active period.
4. Decide whether it creates or updates an accrual/prepaid case.
5. Extract accounting-relevant terms.
6. Prepare or update the accounting case.
7. Run deterministic validations.
8. Notify the accounting manager only when review, evidence, approval, or exception handling is needed.
```

Always-on does not mean an LLM is constantly active. It means the runtime is always watching for accounting-relevant context and wakes bounded agent jobs when work appears.

V1 cadence:

- event-triggered on new inbox artifact
- daily close sweep
- more aggressive sweeps as close approaches

## V1 runtime jobs

The runtime jobs:

1. **Intake classifier:** classifies inbox artifacts as contract, invoice, PO, renewal, schedule, policy, approval, or other.
2. **Vendor linker:** matches artifacts to vendors, aliases, prior cases, and prior schedules.
3. **Term extractor:** extracts amount, dates, service period, billing cadence, renewal terms, approval clues, and relevant source citations.
4. **Case detector:** decides whether an artifact creates or updates an accrual/prepaid accounting case.
5. **Evidence builder:** assembles source docs, extracted fields, prior treatment, and missing-evidence flags.
6. **Treatment proposer:** suggests accrual, prepaid, no-entry-needed, or needs-review, with rationale.
7. **Compiler / validator:** deterministically creates schedules, draft JEs, reversals, duplicate checks, and validation results.
8. **Notification router:** alerts the accounting manager only when action is needed.

## Probabilistic vs deterministic boundary

The model can be probabilistic for interpretation:

- extracting terms from messy artifacts
- identifying likely accounting questions
- proposing treatment rationale
- summarizing evidence
- comparing current context to prior treatment
- drafting reviewer-ready explanations

The accounting compiler must be deterministic for controlled outputs:

- schedule math
- debit/credit balancing
- period allocation
- duplicate accrual checks
- already-invoiced checks
- materiality thresholds
- approval gates
- period locks
- account/entity validation
- audit log creation
- JE export format

Trust boundary:

> The agent proposes accounting work. The compiler validates and materializes it under controls.

## Hard line

The model must never directly mutate accounting books or approved schedules.

It can propose, annotate, extract, and draft. Any mutation of approved accounting state must go through deterministic validation and human approval.

This means:

- no direct ERP posting in v1
- no silent schedule changes
- no closed-period edits
- no unreviewed account mapping changes
- no unlogged policy overrides
- no auto-closing material cases

## Prepared schedules

The first subledger-like state the runtime should own is **prepared accounting schedules**.

For vendor spend, this includes:

- prepaid amortization schedules
- accrual schedules
- contract expense recognition schedules
- renewal / true-up schedules
- reversal schedules
- expected invoice schedules

The schedule is the durable accounting state. The JE is the compiled output.

Every prepared schedule must include:

- source evidence
- treatment rationale
- start and end dates
- recognition pattern
- account mapping
- entity / department / class, where applicable
- period-by-period amounts
- generated entries
- approval state
- lineage back to the accounting case

Every schedule should answer:

> Why does this balance exist, how will it unwind, and who approved the treatment?

## Case completion

A vendor-spend accounting case is complete when:

> The accounting manager has reviewed the proposed treatment, all required evidence is attached, exceptions are resolved or documented, and the system has compiled the needed artifact: prepaid schedule, accrual support, draft JE, or a no-entry-needed conclusion.

Case statuses:

- Detected
- Prepared
- Needs Evidence
- Ready for Review
- Approved
- Compiled
- Closed
- Deferred
- Rejected

Rule:

> A case can only move to Approved if required evidence and deterministic validations pass, or if the reviewer explicitly overrides with rationale.

## Autonomy boundary

The runtime prepares; the accounting manager approves.

Automatically allowed:

- ingest contracts, invoices, renewals, POs, billing schedules, and prior workpapers
- match invoice to contract/vendor
- extract dates, amounts, renewal terms, payment terms, and service periods
- compare against prior treatment
- propose prepaid, accrual, expense, or no-entry-needed treatment
- generate draft schedules and draft JEs
- flag missing evidence or unusual changes
- mark cases as ready for review

Requires human approval:

- final accounting treatment
- posting or exporting journal entries to ERP
- overriding policy
- closing a case with missing evidence
- changing materiality or account mapping rules
- approving unusual or high-dollar treatment

## Controls

Non-negotiable v1 controls:

- no posting without approval
- duplicate accrual / already-invoiced check
- evidence required for material cases
- period locks respected
- every generated schedule links to a case
- every draft JE links to a schedule or case
- every treatment decision has reviewer identity and timestamp
- every model extraction is reviewable against source text
- every override requires rationale
- all changes are logged
- company materiality thresholds are configurable

The top dangerous edge case is duplicate or incorrect accruals. Before compiling an accrual, the runtime must check for:

- matching invoices already received
- prior accruals already booked
- reversal status
- vendor aliases
- PO/invoice/contract relationships
- period and entity
- materiality
- human approval state

## Reviewability principle

Optimize for reviewability and evidence quality first. Recommendation accuracy matters, but controllership trust comes from being able to review the work quickly and safely.

The product wins if an accounting manager can review a case in 2 minutes instead of reconstructing it in 30.

The evidence package is more important than the agent's confidence score.

## First UI

V1 should have three screens:

1. **Accounting Inbox**
   Artifacts landing, classification, extraction status, linked cases.

2. **Close Prep Queue**
   Cases grouped by status, question type, vendor, amount, close impact, and evidence completeness.

3. **Case Review**
   Trigger, evidence, extracted terms, proposed treatment, prepared schedule, draft JE, exceptions, controls, and comments.

No generic dashboard sprawl. No blank-chat homepage.

Chat can exist, but only scoped to a case.

Case-scoped chat examples:

- Why did you propose prepaid?
- Show me the source text for the term dates.
- What changed from last renewal?
- What happens if we use invoice date instead?
- Draft a note to the business owner asking for service confirmation.
- Explain this schedule for reviewer notes.

## Case review screen

Above the fold:

- why this case exists
- proposed treatment
- dollar impact
- close-period impact
- evidence completeness
- required action

Main panels:

1. **Trigger**
   Why the case exists: new renewal, new invoice, open PO near close, missing expected invoice, material change.

2. **Evidence**
   Contract, invoice, PO, approval, prior case, and extracted fields.

3. **Proposed treatment**
   Prepaid, accrual, no-entry-needed, or needs-review, with rationale.

4. **Prepared schedule**
   Period-by-period recognition, account mapping, draft entries, and reversals.

5. **Exceptions and controls**
   Missing evidence, policy deviations, materiality flags, required approvals, and reviewer comments.

## Accounting manager actions

Available actions:

- Approve treatment
- Request evidence
- Edit treatment
- Edit schedule
- Mark no entry needed
- Defer
- Escalate
- Compile artifact

V1 should not make "post to GL" the default action. Use export, staging, or workpaper packet generation instead.

## First demo

The strongest demo is an open PO / missing invoice accrual case, because it proves the runtime acts before the invoice arrives.

Demo flow:

```text
1. Runtime sees an open PO or vendor contract near close.
2. No matching invoice has arrived.
3. It checks term dates, expected billing cadence, prior invoices, approval status, and close calendar.
4. It creates an accrual accounting case.
5. It proposes whether service was likely received/incurred.
6. It drafts accrual support and a reversing JE.
7. It flags missing evidence.
8. Accounting manager approves, edits, or requests confirmation.
```

Evidence needed to propose a missing-invoice accrual:

- contract or PO
- service period
- expected amount or estimate basis
- prior vendor pattern, if available
- evidence that service was received or obligation was incurred

Evidence strength:

```text
Strong:
Approved contract + active service period + recurring historical invoices + amount estimable.

Medium:
Approved PO + service period likely started + prior vendor pattern, but no explicit delivery confirmation.

Weak:
Open PO only, no invoice, no service confirmation.
```

For weak or medium evidence, route a confirmation request to the business owner before approval.

## Design partner proof

The first design-partner motion should be a retrospective close replay.

Pitch:

> Give us your last close's vendor contracts, open POs, invoices, prepaid schedules, accruals, and prior workpapers. We will run the runtime in read-only mode and show which accounting cases it would have prepared before close.

Replay outputs:

- vendor-spend case queue
- case-by-case evidence packets
- extracted contract / invoice / PO terms
- proposed treatment
- generated prepaid or accrual schedules
- draft JE / reversal outputs
- duplicate accrual checks
- missing evidence flags
- comparison to what actually happened in close
- summary of potential time saved / risk surfaced

The killer artifact is a side-by-side:

> What your team did manually vs. what the runtime would have prepared.

## First eval set

The first eval set should be a historical close packet from a design partner.

Inputs:

- vendor contracts
- invoices
- POs
- prepaid schedules
- accrual schedules
- prior workpapers
- final close outputs

Evaluation tasks:

- classify artifacts correctly
- link artifacts to vendors and cases
- extract term dates and amounts
- detect which artifacts should create cases
- propose correct accrual, prepaid, or no-entry-needed treatment
- recreate schedules within tolerance
- avoid duplicate accruals
- identify missing evidence
- produce reviewable workpapers

Metrics:

- case detection recall
- false-positive case rate
- extraction accuracy
- schedule math accuracy
- treatment acceptance rate
- reviewer correction rate
- evidence completeness
- review time reduction

## First prototype

Build a local or lightweight web app where a user uploads an accounting inbox folder for a historical close, sets the active period and thresholds, and the runtime produces a close prep queue of accrual/prepaid cases with evidence, schedules, and draft JE exports.

Prototype sequence:

```text
1. Upload folder / data room.
2. Configure close period and thresholds.
3. Run runtime replay.
4. Review generated case queue.
5. Open case review screen.
6. Approve/edit treatment.
7. Export schedule/workpaper/draft JE.
```

No live integrations required.

## Initial architecture

```text
Accounting Inbox
-> Context Graph
-> Case Engine
-> Agent Workers
-> Deterministic Accounting Compiler
-> Control Plane
-> Review UI
-> Workpaper packet / schedule / draft JE export
```

Core components:

1. **Accounting Inbox**
   Receives messy commercial/accounting artifacts.

2. **Context Graph**
   Normalizes artifacts into vendors, contracts, invoices, POs, close periods, policies, prior treatments, schedules, and cases.

3. **Case Engine**
   Detects accounting questions from triggers.

4. **Agent Workers**
   Run bounded jobs for extraction, linking, rationale drafting, and evidence summarization.

5. **Deterministic Accounting Compiler**
   Builds schedules, draft JEs, reversals, duplicate checks, validations, and export files.

6. **Control Plane**
   Manages statuses, approvals, overrides, audit logs, user roles, and evidence requirements.

7. **UI**
   Accounting Inbox, Close Prep Queue, and Case Review.

8. **Export Layer**
   Workpaper packets, schedules, draft JE CSVs, and reviewer notes.

## Initial data model

Core objects:

```text
Artifact
- uploaded file/email/spreadsheet/source item
- type, vendor, dates, amount, extracted fields, source text refs

Vendor
- name, aliases, prior cases, prior schedules, usual treatment

ClosePeriod
- period start/end, close deadline, thresholds, status

AccountingCase
- trigger, vendor, question type, evidence, proposed treatment, status, exceptions

Treatment
- accrual / prepaid / no-entry-needed
- rationale, policy basis, reviewer decision

PreparedSchedule
- start/end dates, periods, amounts, accounts, generated entries, approval state

CompiledArtifact
- draft JE, reversal, schedule export, workpaper packet

ControlEvent
- review, edit, approval, override, export, comment
```

## What v1 does not do

V1 does not:

- post directly to the ERP
- replace the ERP
- replace AP approval workflows
- support full revenue recognition
- handle all vendor spend categories
- guarantee every accrual is found
- ingest all Slack/email context
- automate auditor signoff
- support complex multi-book/global consolidation
- make final accounting judgments without review

This "no" list is important. It makes the product believable.

## ICP

First ideal customer:

- mid-market or light-enterprise company
- recurring vendor contracts
- monthly close process
- accounting manager or assistant controller owns close
- manual prepaid and accrual schedules in Excel
- AP/procurement data separated from accounting judgment
- audit readiness matters
- not so complex that implementation requires a year

Avoid very small businesses first. They may not feel the pain enough. Avoid the most complex SAP-heavy enterprises until the product is proven.

## What this sits beside

The product creates a new layer between commercial context and the GL.

It sits beside and absorbs work from:

- Excel prepaid/accrual schedules
- close checklist tools
- AP/procurement workflows
- contract repositories
- ERP saved searches/reports
- email/Slack evidence chasing
- workpaper folders

It does not replace the ERP in v1.

## Measurable promise

The first measurable promise:

> Fewer surprise vendor-spend issues during close.

Supporting metrics:

- percentage of relevant vendor-spend cases prepared before close
- average case review time
- missed accruals caught pre-close
- prepaid schedules created from new/renewed contracts
- percentage of cases with complete evidence
- reviewer correction rate
- manual schedule prep hours saved

Avoid promising "faster close" as the first claim. Too many factors affect close.

## Open questions

- What exact artifact bundle should a design partner provide for the first retrospective close replay?
- Should the Accounting Inbox be email-first, folder-first, or app-upload-first?
- What minimum policy configuration is needed for accrual/prepaid treatment to be credible?
- How much COA/account mapping is needed in v1?
- How should the product represent "no entry needed" conclusions so they are auditable?
- What is the right threshold between indexing an artifact and creating a case?
- How should the runtime prevent case noise while still exposing uncertainty aggressively?
- What export format will accounting managers trust first: Excel workpaper, JE CSV, PDF packet, or all three?
- What does a controller need to see to trust a retrospective replay?
- When should prepared schedules become true subledger-like state rather than draft workpapers?

## Short narrative

Every month, accounting managers close the books by reconstructing vendor context: contracts, POs, invoices, approvals, prior schedules, and policy decisions.

But the GL only shows the compiled aftermath. It does not know why a vendor renewal should be prepaid, whether an open PO needs accrual, or whether a missing invoice has already been accounted for.

This product is an always-on close preparation layer for vendor spend. It watches commercial context before close, generates review-ready accounting cases, prepares schedules and draft entries, and gives controllership a controlled path from context to GL.

Close starts with the accounting cases already prepared.