Clearing a ledger's anomalies

Product design, interaction design & prototyping

Turning a list of accounting anomalies into a review workflow, with the evidence and the next action together.

Independent concept · 2026

The review workflow · Related entries can be inspected and resolved together.

Finding an anomaly is only the beginning.

The starting workflow identifies anomalies and proposes corrections. The remaining work sits in a date-sorted list: each row needs individual attention, and the amounts are not visible for comparison.

I focused on the work after detection: understanding the evidence, reviewing related entries and handling the result. Navigation and status names stay familiar. The ledger, identities and amounts are sample data, not client records.

Group the work by its cause.

A chronological list separates entries that may need the same correction. In the sample month, 47 entries share six causes. Grouping by cause makes that relationship visible; opening a group reveals the individual dated entries.

This changes the unit of review without hiding the detail. A bookkeeper can evaluate the shared issue, then inspect individual records wherever the evidence needs a closer look.

The anomaly queue grouped by cause: six rows with counts and amounts, and forty-seven open in the filter. — Six causes, 47 sample entries · Each group shows its count and the amount involved.

Put the action beside the evidence.

The review panel brings together the rule that flagged the entries, the amount involved and the proposed correction. The action states how many entries can be updated. Entries in a locked period are excluded.

The prototype also allows a reviewed decision to become a rule for similar entries. That rule is only saved after all eligible entries have been posted successfully.

Detail of the review panel showing the rule, confidence, amount at risk and VAT code change. — The evidence · Rule, confidence, amount and proposed change.

Detail of the review panel showing affected suppliers, Fix all 20, and the two locked-period entries that remain open. — The decision · Affected entries, the action and the locked-period exception.

Partial success must stay explicit.

A batch can partly succeed. In the simulated failure, 20 entries are submitted, 17 are posted and three are rejected. Successful entries clear from the queue; failed entries stay with a reason and a retry action.

The user can distinguish completed work from work still requiring attention. The interface avoids presenting the whole batch as either a success or a failure when neither is true.

Close-up of the partial-failure message: 17 written, 3 failed, with a Retry 3 action. — Seventeen posted, three to retry · The message separates completed work from the three entries that need another attempt.

Build the states around the real interaction.

I used a component workspace to check idle, hover, pressed, focus, disabled and posting states together. The review exposed missing pressed feedback and a posting action that did not show it was working.

A restrained visual system keeps emphasis on the figures, selected entries and primary action. The prototype and the state workspace use the same components so those decisions remain consistent.

The top of the states sheet: a row of state switches, and the button matrix showing primary, outline and bare in each state. — Component states · Shared controls, including focus and posting feedback.

The prototype covers grouped review, correction and recovery. Testing with bookkeepers would show whether that structure reduces repetitive work without weakening the quality of their review.

Ask me about this work ↗

I designed the product structure, interfaces and interaction states, and built a working front-end prototype. This is independent concept work, not a client commission.