What should you do when a contractor payment fails or has an unclear outcome?
Move the payout into an exception state, preserve the original approved obligation, verify the external provider or bank result, and do not retry an ambiguous payment until you know whether money moved. Resolve the blocker, create a controlled replacement only when required, then reconcile the final outcome back to the original obligation.
- Submitted is not the same as paid
- An internal timeout does not prove the external payment failed
- Blind retries can create duplicate contractor payments
- Every unresolved exception should have one owner
- Close the exception only when the final external outcome reconciles
A contractor payment exception is any payout that cannot safely move from approved to reconciled without review.
The important rule is simple: do not treat “submitted” as “paid,” and do not blindly retry a payment whose outcome is unclear.
A reliable exception workflow preserves the approved obligation, records what the payment provider actually reported, assigns an owner, and resolves the exception before the payment is considered complete.
Direct answer
When a contractor payment fails, is returned, or has an ambiguous result, keep the original approved amount unchanged and move the payout into an exception state. Verify the provider or bank result, identify whether money actually moved, correct the underlying issue, and only then decide whether a new payment should be created.
The goal is to avoid two opposite errors:
- leaving a contractor unpaid because a failed payment looked complete
- paying twice because an uncertain payment was retried too quickly
What counts as a contractor payment exception?
Common exception categories include:
Failed before money moved
The payment provider rejected or could not create the transfer.
Examples can include incomplete payout setup, invalid destination information, or a provider-level eligibility problem.
Returned after submission
A payment was initiated but later returned or reversed.
The operating record should preserve both the original attempt and the return rather than overwriting the first payment as if it never happened.
Ambiguous or unknown result
Your application did not receive a clean final response, a webhook is delayed, or internal state does not yet match provider state.
This is the highest-risk moment for an automatic retry.
Amount or contractor mismatch
The payment request exists, but the contractor, approved amount, job, or destination does not match the obligation that finance intended to release.
Duplicate-risk exception
Two requests may represent the same underlying obligation, or a retry may overlap with a payment that is still resolving.
The contractor payment exception workflow
Use the same sequence every time.
1. Freeze the obligation, not the evidence
Keep the approved obligation intact.
Do not erase:
- contractor
- job or event
- approved amount
- approver
- approval timestamp
- original payment attempt
- provider reference when available
The exception should add state and evidence, not rewrite history.
2. Classify the exception
Use a small set of operational states such as:
- failed
- returned
- pending review
- provider status unknown
- duplicate risk
- destination issue
- amount mismatch
- resolved
A free-text note can explain the situation, but the workflow should not depend on someone reading every note to understand whether money is safe to move.
3. Check the external payment result
Before creating another payout, determine what the payment rail says happened.
The evidence may include:
- provider payment or transfer status
- payment reference
- webhook event
- bank or payout-network result
- return or reversal record
An internal timeout is not proof that the external payment failed.
4. Assign one exception owner
Every unresolved payment should have a person responsible for the next action.
That owner may need to:
- contact the contractor
- correct payout setup
- verify provider state
- review a duplicate
- obtain missing documentation
- approve a replacement payment
- reconcile a return
“Finance is looking at it” is not an owner.
5. Decide whether a replacement payment is actually required
Create a replacement only after the original outcome is sufficiently clear.
If the original payment completed, reconcile it.
If it definitively failed before money moved, resolve the blocker and create the controlled replacement.
If it was returned, preserve the return record and decide whether the obligation is still valid before paying again.
If the result remains ambiguous, continue reconciliation instead of guessing.
6. Link the resolution back to the original obligation
The final record should explain:
- what was approved
- what payment attempt occurred
- what went wrong
- who resolved it
- whether a replacement was created
- which payment ultimately satisfied the obligation
- when the exception was closed
That creates a usable audit trail for operations and finance.
Exception table template
| Field | Example |
|---|---|
| Contractor | Jordan Ellis |
| Job / event | Production 24 |
| Approved amount | $1,275 |
| Original attempt | Transfer reference 123 |
| Exception type | Provider status unknown |
| Owner | Finance operations |
| Next action | Verify provider state |
| Replacement allowed? | No, not yet |
| Resolution | Original transfer confirmed |
| Final state | Reconciled |
The example is illustrative. Use the identifiers and states that match your actual payment system.
Why blind retries are dangerous
A retry can look like the fastest way to help a contractor.
But if the original payment is merely delayed or your application missed the final status, the retry can create a duplicate.
The safer sequence is:
approved obligation → payment attempt → provider evidence → resolved outcome → reconciliation
A second payment should be an explicit new action, not an automatic reaction to uncertainty.
Keep approval separate from payment completion
Approval answers:
Does the business owe this amount?
Payment status answers:
What happened when we tried to satisfy that obligation?
Reconciliation answers:
Does the internal record now agree with the resolved external outcome?
Those are three different questions.
Combining them into one “paid” checkbox hides the exact state that matters during an exception.
What should the contractor see?
Contractor communication should reflect the known state.
Useful language is specific:
- payment approved
- payout processing
- payout needs updated information
- payment attempt failed and is being reviewed
- replacement payment scheduled
- payment completed
Avoid saying a contractor has been paid merely because an internal approval was completed.
How exception handling changes for bulk payouts
A batch should never make individual payment state disappear.
If 24 contractor payments are released and one has an exception:
- the 23 resolved payments should remain resolved
- the exception should remain attached to its contractor and obligation
- the entire batch should not be blindly resubmitted
- the replacement decision should apply only to the affected payment
See the bulk contractor payments guide for the broader batch-control workflow.
Reconciliation closes the exception
An exception is not finished when someone sends a second payment.
It is finished when the team can explain the final state.
Use the contractor payment reconciliation guide to match the resolved payment back to the approved amount, contractor, job or event, payment reference, and accounting record.
Prevent exceptions before payout day
Not every exception is preventable, but readiness controls reduce avoidable failures.
Before release, check:
- contractor record is complete for the supported workflow
- payout setup is ready
- job or event is correct
- approved amount matches the obligation
- required funding state is satisfied
- duplicate risk has been reviewed
- unresolved prior attempts are visible
For the full process, use the contractor payment approval workflow and contractor payment process checklist.
Where Kelvaro fits
Kelvaro is designed to keep contractor readiness, work context, approval, payment state, provider evidence, and reconciliation separate enough that an exception can be investigated without losing the original obligation.
In the current controlled pilot, payment workflows remain scoped to the supported U.S. configuration and its tested controls.
The product should make an unusual payment more explainable, not make it easier to click “pay” twice.
Practical exception checklist
When a contractor payment is not clearly complete:
- Stop automatic retry.
- Preserve the original approved obligation.
- Record the original payment attempt.
- Classify the exception.
- Check provider or bank evidence.
- Assign one owner.
- Resolve the underlying blocker.
- Decide whether a replacement is required.
- Link any replacement to the original obligation.
- Reconcile the final external outcome.
- Close the exception only when the record explains what happened.
Frequently asked questions
Should I retry a contractor payment after a timeout?
A timeout does not establish whether the provider moved money. Preserve the original payment reference, check the provider or bank outcome, and resolve the uncertainty before deciding whether a replacement is needed. See the reconciliation guide for matching the final result to the approved obligation.
Does payment approval mean the contractor has been paid?
No. Approval authorizes an amount; submission, processing, completion, failure, and return are separate payment states. Tell the contractor the verified state rather than treating an approval or submission as proof of completion.
What should happen when only one payment in a batch fails?
Keep the resolved payments intact and investigate the affected contractor obligation individually. Preserve the failed attempt, assign an owner, and link any necessary replacement to that obligation rather than resubmitting the entire batch.
Bottom line
The safest contractor payment system is not the one that never encounters an exception.
It is the one that makes exceptions visible, prevents uncertain retries, preserves evidence, and gives operations a repeatable path back to a reconciled state.