One number, from three systems that disagree
The figure the board asks for exists in three systems, in three shapes. Producing it takes a week, and the three never quite agree.
For a finance director assembling a board packet.
One number, from three systems that disagree
Illustrative sample. Not a client record.
| Account | Item | Status |
|---|---|---|
| FY26-4100 | Permit revenue | Three sources |
| FY26-4200 | Utility billing | Three sources |
| FY26-4300 | Development fees Finance and permitting differ by $18,400. Permitting counts a fee at application, finance at issuance — a timing difference, not an error. | Three sources |
| FY26-4400 | Inspection fees | Three sources |
| FY26-4500 | Franchise fees One vendor feed truncated timestamps, so late-month entries landed in the wrong period. Affects the period split, not the annual total. | Three sources |
Two lines disagree and both have an explanation. Neither is somebody making a mistake — one is a definition difference and one is a vendor feed. Naming that is what makes the number defensible in the room.
Today this is two people, a full day, and a figure in the packet that does not match the figure in the department.
This is a demonstration, not a product. Every record above is invented. The point is not the table — it is that the exception is named, with the field at fault and what it usually means, rather than returned as a code somebody has to decode.
What we would build for you runs on your data, in your environment, and looks like your process rather than this one. More on this category: Data and systems integration.
The other three
- State reporting, validated before submission A district data manager in a submission window
- One permit queue across three departments A permit technician and the departments they chase
- Public records requests, against the clock A city secretary or records officer