← Back to Daily Builds

Daily build note · August 25, 2026

Job Closeout Exception Desk

A local, service-first reconciliation desk that turns job, invoice, communication, and payment exports into a validated closeout-exception queue, supported cash ledger, owner-approved...

Local Business Automations Build note published Public demo coming soon

What shipped

  • A dependency-free Python 3.11+ CLI for sample, generate, decide, and validate.
  • Strict intake for exactly four canonical CSV exports with exact headers, enum/date/cents validation, unique safe IDs, and referential checks.
  • Conservative payment reconciliation: cleared + exact invoice link + consistent job link only, capped allocation, explicit overpayment splitting, and four non-overlapping cash buckets.
  • The six and only six v1 exception rules with fixed severities/actions, direct row evidence, explicit absence boundaries, content-derived IDs, and contact suppression.
  • Atomic rendering of the exception queue, approval queue, supported cash ledger, concise owner brief, and hash-bound deterministic manifest.
  • Versioned local review decisions limited to held, approved, and dismissed; approval cannot send and never changes cash.
  • Two visibly fictional 12-job fixtures whose only difference is one appended exact-linked 185000-cent hero payment.
  • Twenty-five standard-library tests plus a root verify.sh covering hostile intake, rule behavior, exact cents math, determinism under row shuffling, tamper rejection, approval isolation, and the paired cash movement.
  • Fixed-scope $750 USD paid upfront service collateral and a four-export data-fit checklist.

Architecture

  • Split strict CSV parsing, validation, reconciliation, rules, rendering, and CLI orchestration into inspectable modules.
  • Kept core reconciliation/rule functions deterministic and driven by an explicit --as-of date; no clock, randomness, floats, or probabilistic matching enters output.
  • Used integer cents and capped invoice allocations. Cleared job-only or unlinked payments remain unattributed; they are never inferred into paid invoices.
  • Derived finding, action, ledger, and desk IDs from SHA-256 content seeds. Canonical input hashes sort semantic records by source row ID so shuffled source order produces byte-identical outputs.
  • Published outputs through a temporary sibling directory and only replaced outputs/ after model validation.
  • Made validate reload contracts, recompute the entire model, render fresh temporary artifacts, byte-compare all five outputs, and verify hashes/counts/cross-references.
  • Reused only the parent build's broad design patterns—separated concerns, inspectable fictional fixtures, deterministic explanations, human-held drafts, and one verification gate. All schemas, joins, cash math, rules, Python code, fixtures, and collateral are new.

Trimmed scope

  • No browser interface or charting.
  • No vendor adapter, live login, API client, OAuth, webhook, watcher, or scheduler.
  • No sender, collections workflow, invoice/payment posting, source writeback, or automatic action.
  • No database, auth, billing, tenancy, telemetry, model provider, hosted runtime, PDF, or real customer data.
  • No fuzzy entity resolution, AI classification, aging certification, bookkeeping, audit, tax, or general-ledger behavior.

Limitations

  • Results are supplied-files-only and are no stronger than the four sanitized exports.
  • The desk validates its canonical contract but performs no source authentication and has no live access.
  • approved means only a local human decision; the product performs no sending or external write.
  • Cash buckets are supported reconciliation categories, not bookkeeping, audit, attestation, or certification conclusions.
  • No recovered-cash claim is made without a supplied cleared payment that exact-matches a supplied invoice ID and has a consistent supplied job ID.
  • Vendor-specific exports must be transformed to the canonical schema outside this MVP; missing delivery status or identifiers are not inferred.

Suggested next steps

  1. Run one paid review or one qualified sanitized four-export data-fit review before adding engineering scope.
  2. Record vendor-to-canonical mapping friction without adding a live connector.
  3. Tune only contract guidance and fixed reason wording proven confusing in a human readout.
  4. After a successful paid delivery, evaluate a separately scoped human-run recurring review; do not imply automatic monitoring or collections.