A Routable payable status describes a stage in the payment process. It should be read with the payment method, supporting details, and any later notification.
The most consequential distinction is that Completed does not always establish the same event. Routable documents that check payments can be marked completed on their expected delivery date, and that bank payments can occasionally fail after completion when a bank reports an error late. Source: Routable payable status guide.
Start an investigation with the specific payable, not a general account total.
Identify the stage
Routable’s help guide provides these distinctions:
| Status or condition | Meaning to establish |
|---|---|
| Needs approval | Required internal authorization is outstanding |
| Ready to send | No send date has been selected; funds have not started moving |
| Scheduled | Sending is planned for a future date |
| Pending vendor acceptance | Recipient action may still be required |
| In transit / Initiated | The payment has progressed into delivery |
| Failed | An initiated transfer encountered a problem |
| Issue | The transfer could not be initiated |
These descriptions summarize the provider’s status guide; inspect the details of the actual payment. Source: Payable status definitions.
Match the reported problem to the stage
If a payment needs approval, the next action belongs with the authorized reviewer. Asking the recipient to contact their bank does not resolve an internal approval delay.
If recipient acceptance is outstanding, check whether the intended recipient has received and completed the relevant request. Coordinate through the established vendor relationship.
If the payment is in transit, review its expected date and method. A scheduled send date should not be communicated as an arrival date.
The payment methods guide helps distinguish those timing questions.
Read completion details carefully
For a check, investigate issuance and delivery information separately from evidence that the check was deposited or cashed.
Also inspect whether the record says the payment was completed outside Routable. The provider’s guide explains that this can indicate a team member marked it externally paid. Source: Completion notes.
The practical consequence is to locate the underlying evidence. A label cannot replace the bank or payment record needed for the question being asked.
Do not create a replacement solely because the recipient’s description differs from the dashboard label.
Use the documented failure process
Routable’s Dashboard help describes a Resolve failure action on a failed payable. The flow offers paths to request a retry, create a support ticket, or cancel the payable. It is documented as a Dashboard workflow rather than an API feature. Source: Resolving Failed Payments in the Dashboard.
Read the reported failure reason first. A receiving-account problem calls for a different investigation from an unclear processing error.
If a recipient update is needed, use the appropriate verified process and account permissions. Do not treat an unexpected email with new banking details as sufficient evidence by itself.
A retry request is not proof of a completed retry
The failure guide states that the retry option sends a request to Routable support for processing. Resolution time depends on the failure. Source: Routable retry instructions.
Record that the request was submitted, then monitor the resulting outcome. Avoid telling the vendor that money has been resent until the record supports that statement.
Keep the original payable reference in the case. Creating a new payable without resolving the old one can make it harder to determine which obligation remains open.
Consider the accounting effect of cancellation
Routable’s failure documentation describes choices affecting whether cancellation applies only in Routable or also in connected accounting software. It specifically warns that a Routable-only deletion can leave a QuickBooks Online mismatch requiring attention. Source: Cancellation and ledger treatment.
Confirm the intended accounting result before submitting the action.
Use the integration guide to reconcile the resulting records. If the business pays through another route, preserve the evidence and connect it to the original obligation.
Close the case with an explained outcome
The resolution record should identify the payable, the problem, the action requested, and the verified result.
Separate “support contacted” from “payment resolved.” If the case remains open, assign an owner and the next check.
That makes follow-up more accurate for both the vendor and the accounting team.