Invoice workflow software is usually compared on how the happy path looks and should be compared on how it handles the invoices that leave it. Real invoices go backwards, get disputed, turn out to be duplicates and arrive for cost centres nobody configured. Three design properties decide whether those cases stay inside the system or migrate into email.
States rather than a sequence
Received, matched, in exception, awaiting approval, approved, scheduled, paid, disputed, cancelled. A state machine accommodates an approved invoice turning out to be a duplicate; a strict sequence does not, and forces that case out into email where nothing records it. Ask specifically whether backwards transitions are possible and logged.
An owner on everything
Each state assigns a named person rather than a group. Group queues produce items everybody can see and nobody progresses, and the effect is worst in the exception states where the work actually is. Reassignment should be easy, because the first owner is often not the right one.
An age on everything
How long an invoice has been in its current state, visible and reportable. Without it there is no difference between an item stuck for a day and one stuck for a quarter, and the weekly management routine, chase the oldest three in each state, becomes impossible. This is the cheapest feature to have and the most often missing.
Questions people ask about invoice workflow software
How many states is right?
Enough that each has a distinct owner and action. Six or seven covers most situations; more usually means duplicates nobody distinguishes.
Should the software prevent backwards moves?
No. It should permit and record them, or people will do the work outside it and the record will silently be wrong.
What should be reported?
Counts by state and the oldest age in each. Two small tables that fit on a page.