Processed is the most common and least useful status in payables. Ask three people in the same team what it means and you will often get captured, approved and paid. That ambiguity is not pedantry: it means the queue cannot be counted, targets cannot be set, and two people discussing the same invoice can genuinely believe different things about where it is.
Replace it with states that name an action
Received, matched, in exception, awaiting approval, approved, scheduled, paid. Each names a condition somebody can act on, and each has an obvious owner. Processed names none of those. Replacing one vague status with a short explicit list is usually a day's work and immediately makes the queue reportable.
Why the ambiguity is expensive
A supplier asking whether their invoice has been processed wants to know whether they will be paid. An auditor asking wants to know whether it was authorised. A manager asking wants to know whether it is off the desk. One word cannot answer three questions, and answering the wrong one produces a supplier who expects money that is not scheduled.
Keep the list short
More states are not better. If somebody cannot recite the list, it is too long, and states that nobody distinguishes in practice get used interchangeably, which reintroduces the ambiguity you removed. Each state should correspond to a different owner or a different next action, and nothing else earns a place.
Questions people ask about invoice processed
What should we tell a supplier who asks if their invoice is processed?
Tell them the state and the expected payment date. Those two facts answer the question they are actually asking and prevent the follow-up call.
Is approved the same as processed?
Only if you define it so and everybody knows. The point is the definition being explicit, not which word you choose.
How many states should a small team have?
Five or six is plenty. Received, matched, in exception, awaiting approval, approved, paid covers nearly every situation.