Every small and mid-market business has implicit routing logic for documents. An invoice over a certain amount needs finance to sign off. A new vendor needs legal review before the first payment. An employee expense reimbursement above a threshold goes to a senior manager. A certificate of insurance needs to match coverage requirements before the vendor can be activated.
That logic exists. The problem is that it lives in people's heads rather than in a system. So every time a document arrives, a person has to remember the rule, apply it, and route manually. When that person is out, the routing either stops or gets done wrong. When a new employee joins, the rules have to be transmitted verbally. When the rules change, there is no central place to update them.
Encoding routing logic is not complex. What makes it feel complex is the upfront work of making implicit rules explicit.
Document Classification as the Starting Point
Before routing can happen automatically, the system needs to know what type of document it is looking at. Document classification is the first step in any intelligent document processing (IDP) pipeline: the incoming file is analyzed and assigned a document type from a known set of categories.
For a typical back-office workflow, the relevant document types include: vendor invoice, purchase order, expense report, W-9 or tax form, certificate of insurance (COI), bank authorization / ACH form, signed vendor agreement, and shipping confirmation. Each type has different extracted fields, different routing rules, and different approver chains.
Classification is done at the document level, not the file level. A single PDF can contain multiple document types, though this is uncommon in practice for most SMB operations. More relevant is that the same file extension (PDF) covers wildly different content types. A PDF is not a document type. A vendor invoice is a document type. The classification step makes that distinction.
Routing Dimensions: Type, Amount, Vendor Status, and Exception Flags
Once a document is classified, routing decisions are typically based on a combination of four dimensions:
Document type. An invoice always goes to accounts payable. A signed contract always goes to legal or operations leadership. An expense report goes to the employee's direct manager. These are base-level type-to-approver mappings.
Amount thresholds. Most organizations have spending authority rules: the operations manager can approve invoices up to $2,500; the VP of Finance approves up to $25,000; anything above that requires CEO sign-off. These thresholds should be encoded as conditions, not tribal knowledge.
Vendor status. A document from a vendor who is already in your system with verified banking and tax details follows a different path than a document from a vendor who has never submitted a W-9. New vendor status should trigger an onboarding sub-workflow before the document proceeds to normal AP approval.
Exception flags. Documents with extraction anomalies, such as an amount that does not match the referenced purchase order, a vendor address that differs from the one in your system, or a missing required field, should route to a review queue rather than to the normal approval chain. An exception is not a failure; it is a signal that human judgment is needed at that specific decision point.
Encoding the Logic: Conditions Over Hardcoded Rules
A common mistake when first building document routing is to hardcode specific rules for specific vendors. "Invoices from this vendor go to this person." That works for a small vendor list but does not scale and breaks every time staff or vendors change.
A more durable approach uses conditions rather than named assignments:
- If document type is Invoice AND amount is less than $5,000 AND vendor is in approved vendor list: route to Operations Manager for approval.
- If document type is Invoice AND amount is $5,000 or more: add Finance Lead to approval chain before Operations Manager.
- If document type is Invoice AND vendor is NOT in approved vendor list: trigger vendor onboarding workflow first, hold invoice until onboarding is complete.
- If document type is COI: route to Procurement to verify coverage matches minimum requirements.
- If document type is W-9 or ACH Authorization: route to Finance for vendor record update.
These conditions reference roles, not individuals. When the Finance Lead changes, you update the person assigned to the Finance Lead role once, and every routing rule that references that role updates automatically. This is the difference between a routing system and a routing workaround.
Sequential vs. Parallel Approval Chains
Not all multi-step approvals need to happen sequentially. An invoice that requires both operations and finance sign-off can often run those approvals in parallel, with final confirmation after both are received. Sequential approval means waiting for each step before triggering the next. Parallel approval notifies both parties simultaneously and waits for both to respond before proceeding.
For most SMB invoice workflows, sequential is simpler and sufficient. Approval amounts are small enough that one approver is reviewing while the other is notified. Parallel becomes valuable at higher document volumes where the sequential wait time adds up, or for time-sensitive payments where a 24-hour approval window is tight.
The routing configuration should specify the chain structure explicitly: who approves, in what order, and whether any step can run in parallel with another. Leaving this implicit means the behavior depends on the implementation details of whatever tool you are using, which is a support ticket waiting to happen.
What Happens When the Approver Is Unavailable
Every routing design needs to address absence. If the approver for a specific document is out of office, what happens? The options are: the document waits indefinitely, the document escalates to a defined backup, or the document auto-approves after a defined timeout if the amount is below a certain threshold.
All three are legitimate choices depending on context. An invoice from a routine vendor for $400 probably should not wait three weeks because the manager is on vacation. A vendor agreement for a new $50,000 supplier relationship probably should not auto-approve because the VP was at a conference.
The important thing is that these escalation rules are defined in the system rather than handled ad hoc via Slack messages. "Hey, can you approve this while Sarah is out?" is not an approval chain. It is a workaround that generates no audit record and depends on people remembering to act.
Practical Starting Point for Teams New to Routing Automation
If your organization has no formal routing rules currently, starting with a complete encoding of all document types and all possible conditions is more than necessary. The useful minimum starting point is three things:
First, identify the two or three document types that have the highest volume and the clearest approval logic. Invoices from known vendors are usually the right starting point: there are many of them, the routing logic is well-understood, and errors are visible quickly.
Second, define the conditions for each type at the level of: "who approves, under what conditions, and what triggers an exception." Write this out before building anything. The act of writing it down will surface inconsistencies in the current process that are worth resolving before they are encoded into software.
Third, run the configured routing on a subset of live documents for one to two weeks before removing humans from the loop entirely. The first week will surface edge cases you did not anticipate. Those edge cases are valuable: they reveal where the routing logic needs refinement and where new exception conditions need to be added.
Document type classification and routing logic are not glamorous problems. They are also not optional if you want back-office automation that works reliably at volume. The investment in getting the logic explicit and encoded is a one-time cost. The benefit is that the routing happens correctly every time, without anyone having to remember the rules.