BalanceDocket

Evidence-bound month-end review: rules calculate, GPT-5.6 interprets, humans decide.

Comment

Inspiration

Month-end close exceptions rarely live in one place. The calculation may be in a spreadsheet, the source wording in an invoice, the policy in a separate document, the model discussion in chat, and the final sign-off somewhere else. Controllers do not need another autonomous-accountant claim; they need a defensible chain showing what the source said, what the rules calculated, what the model contributed, and which human made the accountable decision.

BalanceDocket was inspired by that missing chain. Its design starts from the reviewer's evidence and authority boundaries, then gives GPT-5.6 one useful, inspectable interpretive role inside them.

What it does

Month-end review often splits one decision across a ledger export, invoice, policy note, spreadsheet calculation, chat thread, and sign-off record. That makes it difficult for a reviewer to answer four basic questions: What source supports this? Who did the calculation? What did the model contribute? Who made the accountable decision?

BalanceDocket turns that fragmented review into one evidence-bound path. The bundled synthetic case follows Nordix Services AB's June 2026 close. A text PDF invoice covers service from June 15, 2026 through June 14, 2027. Deterministic controls establish that 16 of 365 inclusive service days belong to June, producing exactly SEK 5,260.27 expense and SEK 114,739.73 prepaid asset. The Adjustments stage remains blocked for human review, and downstream close stages wait visibly on that decision.

The reviewer opens a proof sheet that keeps source excerpts, hashes, dates, calculation, model interpretation, uncertainty, and human authority in separate layers. In the judged flow, GPT-5.6 performs the bounded interpretive step: it connects the ambiguous invoice wording and policy to the exact control result, selects supporting citations, exposes uncertainty, and flags missing evidence. It cannot change the calculation or claim to approve, post, lock, pay, file, send, or execute. The reviewer must enter a rationale and choose Approve treatment, Request evidence, or Reject. BalanceDocket then records a snapshot-bound, append-only hash-chained event and exports a JSON workpaper. The export reports zero accounting actions and zero ERP writes.

The deterministic baseline remains model-free, network-off, API-free, and does not require an OpenAI account. That fail-safe path does not replace GPT-5.6's material role in the competition flow. The judged advisory route uses the operator's existing Codex sign-in when their plan is eligible. The optional Responses API route is a separate integration with explicit opt-in, an OPENAI_API_KEY, and separate billing and limits. A ChatGPT subscription is an interactive product entitlement, not an API credential.

How we built it

The product combines a Python evidence, controls, advisory-validation, and decision-chain layer with a React and TypeScript reviewer built with Vite. The browser UI is served from a loopback-only Python service, while the same tested frontend is checked into the repository as a judge bundle so the core workflow can run without rebuilding or installing Node.js.

The end-to-end workflow is:

  1. Generate the bundled synthetic GL, policy, and text-based invoice pack.
  2. Run exact duplicate, cutoff, and prepaid controls locally.
  3. Bind source citations and SHA-256 hashes into a stable evidence snapshot.
  4. Show the existing nine-stage close dependency model, with one Adjustments exception blocking the dependent stages.
  5. In the judged flow, request a strict, citation-bound GPT-5.6 advisory through Codex. Manual ChatGPT import and a separately opted-in Responses API route are fallback transports; deterministic review remains the fail-safe when no model route is available.
  6. Reject malformed output, unknown citations, changed amounts, stale snapshots, or claims of accounting authority.
  7. Require a human rationale and disposition.
  8. Append a hash-chained decision event and export the evidence-bound workpaper, without making an external accounting change.

How Codex and GPT-5.6 were used

Codex accelerated rules research, repository inspection, architecture, implementation, UI iteration, test generation, browser verification, safety hardening, and submission preparation. The human entrant selected the problem, persona, track, risk boundary, product shape, and release tradeoffs, then reviewed the resulting behavior against repository evidence and competition requirements.

GPT-5.6 has one material but bounded product role: interpret the synthetic invoice wording and policy in the context of the exact deterministic result, select supporting citations, expose uncertainty, and flag missing evidence. Provider prose is discarded; BalanceDocket renders a local controlled-language summary for the human reviewer. GPT-5.6 does not own arithmetic or decision authority.

For the retained real run, Codex requested gpt-5.6-sol and structured output was validated, but Codex CLI 0.144.0 did not report returned model identity. The raw authenticated advisory-run identifier is retained privately and deliberately excluded from public documentation. It is advisory provenance, not the submission's required /feedback session ID.

Pre-existing project disclosure

BalanceDocket extends the pre-existing Accounting Agent repository. The baseline before Build Week is commit aed4507d0c59eeda1ec9ccfbdeffd8fb8c550522, dated July 11, 2026. It already contained synthetic accounting proposal workflows, evidence primitives, dependency-aware close readiness, provider-neutral model-routing foundations, guarded read contracts, a local operations cockpit, and the no-live-write boundary.

Work added after the July 13 competition start includes the dedicated BalanceDocket golden case, invoice parser/generator, exact close controls, snapshot and citation contract, bounded advisory evaluator, human decision chain, loopback service, React reviewer, JSON workpaper, Codex plugin skill, tests, visual design, demo flow, and competition documentation. The detailed file-level boundary and retained hashes are documented in docs/build_week_provenance.md.

Challenges we ran into

The hardest product challenge was giving GPT-5.6 a material role without allowing model prose to become accounting truth. We separated deterministic amounts and dates from interpretation, required a strict citation-bound schema, rejected changed amounts or unsupported authority claims, and rendered only a locally controlled summary of validated selections.

Provenance required the same discipline. Codex requested gpt-5.6-sol, but the CLI version used for the retained run did not report the returned model identity, so the product and submission say exactly that instead of overstating the evidence. The original repository history also contained private workspace metadata, which required a sanitized public root and a documented pre-existing work boundary rather than publishing the development ancestry.

Accomplishments that we are proud of

  • One coherent synthetic workflow now runs from invoice and policy evidence to exact integer-öre allocation, bounded GPT-5.6 interpretation, a human disposition, and a hash-chained workpaper with zero ERP writes.
  • The checked-in judge bundle runs with Python 3.11+ and no rebuild, account, API key, model, or network connection.
  • The release verifier passes 17 focused BalanceDocket tests, 32 frontend tests, the production build and bundle-parity check, and 344 full repository tests.
  • The reviewer has responsive, keyboard, VoiceOver, Safari, Firefox, WebKit, reduced-motion, zoom/reflow, and automated accessibility coverage.

What we learned

Trustworthy AI in accounting is primarily a boundary and provenance problem, not a prompt-writing problem. A model becomes more useful when its job is narrow enough to validate: interpret cited wording, expose uncertainty, and flag missing evidence, while deterministic controls and the accountable human retain their own clearly labeled authority.

We also learned that a free, local, no-rebuild judge path improves both product resilience and evaluation clarity. The same fail-safe path that helps a judge inspect the workflow without credentials is the path a controller can still use when a model route is unavailable.

What's next for BalanceDocket

The next validation step is five structured walkthroughs with controllers or accounting managers using the synthetic case. Those sessions should test whether the evidence layering, rationale gate, and exported workpaper reduce review ambiguity before any claim about production time savings is made.

After that evidence, narrowly scoped import adapters and additional close exceptions can be added behind the same synthetic-first, no-write, explicit permission, and idempotency boundaries. Live posting, payment, filing, and client communication remain outside the current product.

Built With

Share this project:

Updates