# Customer Account to Collection

This workflow follows an on-account sale from its source transaction through aging, statement review, approved finance charges, safe collection, and balance application. It keeps the reason for the receivable visible while separating customer communication, provider response, settlement, and accounting application.

> **Demonstration notice:** All displayed data is fictional. Email delivery and payment-provider calls are suppressed; pending test records do not represent collected or settled funds. Finance-charge policy requires business and legal review.

<h2 id="bkmrk-glance">Workflow at a glance</h2>

| | |
|---|---|
| **Outcome** | A customer balance reviewed and reduced through a supported application |
| **Starts with** | An authorized on-account sale |
| **Ends with** | Updated receivable history and an explained remaining balance |
| **Primary roles** | Salesperson, receivables clerk, accounting manager |
| **Brisk areas involved** | Customers, Sales, Receivables, Statements, Payments |
| **Common businesses** | Wholesale, service, parts, property and commercial accounts |
| **Approximate handoffs** | Three |

<h2 id="bkmrk-why">Why this workflow matters</h2>

Collections become unreliable when staff cannot connect a balance to the sale, due date, statement, charges, credits, and payment applications that produced it. Brisk retains that history under the customer instead of reducing the work to one editable balance.

Remote payments add another boundary. A request can be created, accepted, settled, and applied at different times. Staff should confirm each state rather than treating a link or uncertain response as cash.

<h2 id="bkmrk-prerequisites">Before you begin</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelmanagementcustomer-detail-customer-detail.png" alt="Customer detail for fictional customer DOC-C-001 with terms and account context." loading="lazy" style="max-width:100%;height:auto;"><figcaption>Terms, contact information, and account status should be correct before extending credit.</figcaption></figure>

- Required: correct customer, terms, contact information, account status, and authorized credit policy.
- Required: a finalized sale in Receivable status and a defined report cutoff.
- Required for charges: configured finance-charge group and payment-term eligibility plus management approval.
- Optional: configured sandbox email-payment provider or an authorized receivable payment plan.

<h2 id="bkmrk-steps">End-to-end steps</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-screenaccountingreceivables-aging-ar-aging-report.png" alt="Accounts Receivable Aging report for the deterministic documentation cutoff." loading="lazy" style="max-width:100%;height:auto;"><figcaption>Aging separates current and overdue balances at a stated cutoff; it is not the live balance by itself.</figcaption></figure>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/sales-customer-order-draft.png" alt="Fictional sale DOC-SALE-1001 with an outstanding balance prepared for the collection example." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The source sale explains why the customer balance exists.</figcaption></figure>

1. **Sales or credit staff — verify the customer.** Review [Customers](https://help.brisksystems.us/link/2680#bkmrk-detail), including terms, group, credit limit, email, and account status.
2. **Salesperson — finalize the source sale on account.** Review the [Sale](https://help.brisksystems.us/link/2746#bkmrk-detail), due-date inputs, and Receivable payment status. Confirm the obligation in [Receivable Transactions](https://help.brisksystems.us/link/2586#bkmrk-overview).
3. **Receivables clerk — review aging.** In [Receivables, Statements, and Finance Charges](https://help.brisksystems.us/link/2946#bkmrk-aging), set a defined cutoff and review current, overdue, credit, and zero-balance context together.
4. **Receivables clerk — preview the statement.** Choose the customer and period, inspect opening activity, invoices, payments, credits, charges, and ending balance. The fixture suppresses sending.
5. **Accounting manager — decide on finance charges.** Use Preview first. Apply only eligible, approved rows from the current preview token; do not use a charge to compensate for bad terms or a missing payment.
6. **Authorized collector — record the collection path.** Create a sandbox [Email Payment](https://help.brisksystems.us/link/2970#bkmrk-overview) or record a safe customer account payment. Confirm provider outcome before treating it as complete.
7. **Receivables clerk — apply and verify.** Apply the customer credit or payment to the intended receivable, then review the customer inquiry and ending balance. A [Customer Receivable Payment Plan](https://help.brisksystems.us/link/2969#bkmrk-overview) is an optional authorized branch, not the default.

<h2 id="bkmrk-connected">What Brisk keeps connected</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-screenaccountingreceivables-finance-charges-finance-charge-form.png" alt="Finance Charge preview screen for fictional eligible receivables." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The preview is a decision point; policy, terms, dates, and eligibility still require review.</figcaption></figure>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-screenaccountingreceivables-statements-customer-statement-form.png" alt="Customer Statement form scoped to fictional documentation customer DOC-C-001." loading="lazy" style="max-width:100%;height:auto;"><figcaption>Preview the statement before any external delivery and correct source transactions rather than its output.</figcaption></figure>

| Action | Result or downstream record | Where to verify it |
|---|---|---|
| Finalize on account | Source sale and receivable obligation | Sale detail and receivable inquiry |
| Run aging or statement | Cutoff-based presentation of saved transactions | Aging report and statement preview |
| Apply a finance charge | New customer obligation when approved and applied | Applied-charge list and customer history |
| Collect and apply payment | Provider/payment record plus receivable application | Payment detail and receivable inquiry |

<h2 id="bkmrk-handoffs">Handoffs and controls</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelaccountingreceivabletransaction-overview-ar-inquiry.png" alt="Receivable inquiry for fictional customer DOC-C-001 showing account transaction history." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The final inquiry verifies invoices, charges, payments, credits, and the remaining customer position.</figcaption></figure>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelebizchargeemailpayment-detail-email-payment-detail.png" alt="Sandbox email payment detail for fictional customer DOC-C-001 with sensitive values masked." loading="lazy" style="max-width:100%;height:auto;"><figcaption>A saved payment request has a provider state separate from accounting application.</figcaption></figure>

Sales establishes the valid obligation; receivables communicates it; management approves policy-sensitive charges; authorized payment staff verify provider results and application. The source sale and receivable transactions remain evidence. Generated statements communicate that evidence but do not alter it.

<h2 id="bkmrk-exceptions">Exceptions and safe corrections</h2>

- Wrong due date or terms: correct approved setup or source data before charging.
- Statement disagrees with the customer: trace its cutoff, payments, credits, and original sale; regenerate after correction.
- Pending or failed payment: inspect provider and Brisk states before retrying.
- Incorrect posted charge: use an approved credit or adjustment that preserves history.
- Uncertain plan run: verify subscription and transaction history before another attempt.

<h2 id="bkmrk-related">Related documentation</h2>

### Start here

- [Customers](https://help.brisksystems.us/link/2680#bkmrk-overview)
- [Sales](https://help.brisksystems.us/link/2746#bkmrk-overview)

### Continue with

- [Receivable Transactions](https://help.brisksystems.us/link/2586#bkmrk-overview)
- [Email Payments](https://help.brisksystems.us/link/2970#bkmrk-overview)
- [Customer Receivable Payment Plans](https://help.brisksystems.us/link/2969#bkmrk-overview)

### Related controls and reports

- [Receivables, Statements, and Finance Charges](https://help.brisksystems.us/link/2946#bkmrk-overview)

<aside class="brisk-workflow-cta" aria-label="Brisk demonstration">
<h2>Could Brisk Simplify This Process for Your Team?</h2>
<p>See how this workflow could be configured around your records, permissions, approvals, and reporting requirements.</p>
<p><a href="https://brisksystems.us/quickbooks-alternative/">Request a focused Brisk demonstration</a></p>
</aside>