Invoice workflows are usually drawn as a sequence and behave as a state machine, and the difference matters. Real invoices go backwards: an approved invoice turns out to be a duplicate, a matched one is disputed, a paid one is credited. A model built as a strict sequence has nowhere to put those, so they leave the system and continue by email, which is where visibility is lost.
Define states, each with an owner
Received, matched, in exception, awaiting approval, approved, scheduled, paid, disputed, cancelled. Each is a place an invoice can legitimately sit, each has somebody responsible, and each has an age. This is a more honest model than a sequence because it accommodates the transitions that actually occur rather than only the happy path.
Allow backwards transitions, and record them
An invoice can go from approved back to disputed. From matched back to exception when a credit note arrives. Systems that forbid these force people out into email to handle them, and then the record is wrong in a way nobody notices. Permitting the transition and recording who made it keeps the history intact.
Report on states, not on throughput alone
How many invoices are in each state, and how old the oldest is. That view tells you where to intervene today, which a throughput figure does not. It also makes the exception queue impossible to ignore, which is usually its main problem: everybody knows it exists and nobody sees its size.
Questions people ask about workflow invoice processing
Is a strict sequence ever right?
For a very simple process with few exceptions it is simpler to build and to explain. The question is what happens the first time something needs to go backwards.
How many states are too many?
If somebody cannot recite them, there are too many. Each additional state should correspond to a genuinely different owner or a genuinely different action.
Where do disputes belong?
In their own state with an owner and an age. Parking them in a general exception queue is how a dispute ages for months and becomes a relationship problem.