Finance teams are the harshest usability testers in any company. They use the system every day, they are accountable for the numbers, and they have no patience for a beautiful interface that cannot reconcile an account.
Start from the paper
We begin with the documents the team already trusts: the invoice, the receipt, the monthly summary. The screen is designed to produce those documents exactly, then improved from there.
States, not screens
An invoice is not a page. It is a state machine: draft, sent, partially paid, paid, overdue, void. Designing the states first prevents the most common failure — a status that looks correct but cannot be reversed.
Numbers must be inspectable
Every total should be explainable by clicking it. Subtotal, discount, tax and amount paid must each carry their own arithmetic, because a finance officer will eventually need to defend the number to someone else.
Access is part of the design
A salesperson should see the customer and the order. They should not see payroll or the full margin report. Role boundaries belong in the interface, not only in the database.
Measure adoption, not features
A module is finished when the team uses it without being reminded. Until then it is a prototype with production styling.