Payment requests

Payment requests are operational records used to ask a customer for an expected payment. They may include the customer, related contract, amount, due date, reason, notes, creator, and status.

A request helps coordinate communication and collections. It does not create a payment or alter the customer's balance.

Request statuses

The supported statuses are:

• Draft — prepared but not yet sent or formally issued.
• Sent — the request was issued through the supported process.
• Paid — a corresponding verified ledger payment has been confirmed according to the workflow.
• Cancelled — the request is no longer active and the reason should be clear.

Do not mark Paid because the customer says they paid or because proof was received. Confirm the payment record.

Before creating a request

Confirm:

• correct customer and contract;
• amount and purpose;
• contract due date or approved reason;
• whether another active request already exists;
• latest payment and collections activity;
• appropriate recipient/contact information; and
• follow-up owner.

Creating and sending

1. Open the correct customer or account.
2. Review contract and payment history.
3. Enter amount, due date, and clear reason.
4. Save as Draft when another person must review it.
5. Preview any related notification.
6. Send or issue once through the supported process.
7. Confirm status became Sent.
8. Record collections follow-up and due date.

Monitoring the request

Review:

• whether the customer was contacted;
• whether the due date passed;
• whether proof or a payment was received;
• whether Finance verified and recorded it;
• whether the request amount still matches the account; and
• whether cancellation or correction is needed.

Marking Paid

Before marking Paid:

1. Open Payments.
2. Confirm customer, contract, amount, date, method, and reference.
3. Verify only one payment exists.
4. Confirm Finance completed the required review.
5. Link the request and payment where supported.
6. Update status and record any remaining difference.

If the buyer paid a different amount, do not force the request to Paid without following the approved partial-payment or correction process.

Cancelling

Cancel when the request was created in error, replaced, no longer required, or superseded by an approved arrangement. Preserve the reason and review whether any queued email or collections task also needs to be cancelled.

Example: request sent, proof received

A BZ$300 request is Sent to Marlon Training.

1. Collections records the communication.
2. Marlon submits transfer proof.
3. The request remains Sent while Finance verifies it.
4. Finance records the actual payment.
5. The request is linked or marked Paid according to the workflow.
6. Collections confirms the account and closes the follow-up.

Common mistakes

• Creating duplicate requests for the same amount/date.
• Sending without verifying the customer email.
• Treating Sent as delivered or paid.
• Marking Paid from proof alone.
• Cancelling without stopping related notifications/tasks.
• Leaving expired Draft requests in active work.

Suggested training media

Screenshot space: Add a payment-request form showing customer, contract, amount, due date, reason, notes, status, and notification preview.

Screenshot space: Add a request timeline showing Draft → Sent → verified Payment → Paid, plus a separate Cancelled example.

Diagram space: Add a request lifecycle with a verification gate between customer proof and Paid status.

Video space: Record a 6-minute walkthrough creating a fictional request, sending it, receiving proof, verifying the ledger payment, and completing the request.