Accounting system specification for a pawnshop network

The task

Pledges in the network are registered in PawnExpert: the program is required for reporting to the regulator and stays the main one. Everything else is kept in Excel per branch: cash, metal purchases, sales, the fate of items the client never redeemed. The owner gets a network summary by calling staff. Where an unredeemed item went is not visible right away, and manual records leave room for errors and abuse: cash discrepancies, understated weight at purchase.

Assessment

Before design, PawnExpert exports and branch Excel sheets were analysed: which fields exist, where the data diverges, what is missing for a summary. The main constraint showed up at once: PawnExpert has no API, so a new system can only read its export. Rules that are not in the data added up to nine questions for the owner, among them the loan-to-valuation limit, staff bonuses and purchase price ranges.

Specification

The specification follows the ANSS standard. The system complements PawnExpert: a Telegram bot sends the owner a network summary at 9:00, deadline alerts and buttons to decide what happens to an unredeemed item; a web app gives staff cash, purchases, item tracking and shifts on their phones. The boundaries are written down: PawnExpert is not replaced, the Excel archive is not migrated.

Five invariants protect what the owner needs the system for. No item is accepted without a photo. One contract cannot be entered twice. Operations are never deleted, only flagged with who did it and why. Only the owner chooses where an unredeemed item goes. A per-gram purchase price outside the range waits for his approval. Every requirement has acceptance criteria.

Review before code

Before development, a Claude Code agent read the specification under one rule: more than three problems, no code. The agent stopped and reported about 15 issues, four of them blocking: no real PawnExpert file to parse, database tables missing although relations already point to them, no formula for the expected cash balance, nothing on what happens to a pledge that disappears from the export. In code, each of them would have meant rework. The anonymised specification and the agent's review are published as an example in the ANSS repository.

Result

The data assessment, the specification with the agent review, a staff screen prototype and a staged proposal are ready. The owner postponed the rollout. The system was not built, so there are no measurements.

What carries over today

When records depend on a program without an API, the assessment starts with what data can be taken out of it and in what form. Invariants fix what the system must never allow. Reviewing the specification with an agent before code catches errors while fixing them costs one line of text.