Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt

Use this file to discover all available pages before exploring further.

How to Record Customer Payments

Customer payments in DualEntry record money received against outstanding invoices. You can apply a single check to one invoice, spread a payment across multiple invoices, process a batch deposit, or record prepayments and deposits for future application.

Applying Payments to Invoices

Navigate to Accounts Receivable → Receive Payment, or send a POST to /public/v2/customer-payments/. Select the customer, enter the payment amount and date, and choose the bank account where the funds were deposited. DualEntry displays all open invoices for that customer. Allocate the payment across one or more invoices. You can auto-apply (oldest invoice first) or manually assign amounts to specific invoices. The payment posts a debit to the bank account and a credit to accounts receivable, clearing the allocated portion of each invoice. When using auto-apply, DualEntry allocates the payment starting with the oldest open invoice and works forward until the payment amount is exhausted. If the payment does not cover all open invoices, the remaining invoices stay open with their original balances. You can override the auto-apply suggestion and reallocate manually before confirming.

Partial Payments and Batch Deposits

You are not required to pay an invoice in full. Enter any amount less than the invoice balance, and DualEntry records a partial payment. The invoice remains open with a reduced balance and continues to appear in your aging report until fully satisfied. Partial payments are common in milestone billing, disputed invoices, or installment arrangements. Each partial payment is tracked individually so you have a complete payment history per invoice. The invoice detail view shows every payment applied, with dates and amounts, giving you a clear picture of the collection timeline. When you receive multiple customer payments in a single bank deposit - for example, a stack of checks deposited together - use the batch deposit workflow. Create a deposit record, add each customer payment as a line item, and enter the total deposit amount. DualEntry validates that the individual payments sum to the deposit total. The batch deposit creates a single bank transaction that matches against the cleared deposit in bank reconciliation.

Prepayments and Deposits

Customers sometimes pay before you issue an invoice - as a retainer, deposit, or advance payment. Record these through /public/v2/customer-prepayments/ or /public/v2/customer-deposits/. The entry debits the bank account and credits a customer prepayment liability account (not revenue). When you are ready to apply the prepayment, use /public/v2/customer-prepayment-applications/ to allocate it against one or more invoices. The application reclassifies the liability to revenue and clears the invoice receivable. You can apply a prepayment partially - the remaining balance stays available for future invoices. Customer deposits and customer prepayments serve different accounting purposes. Deposits typically relate to specific future goods or services, while prepayments are general advances. Choose the record type that matches your recognition policy. Both record types appear on the customer’s account balance, so you always know how much unapplied credit a customer has available.

Overpayments and Payment Matching

If a customer sends more than the invoice balance, you have two options:
  • Leave the credit on account - DualEntry records the excess as a customer credit that can be applied to future invoices. The credit appears in the customer’s balance.
  • Refund the overpayment - issue a refund for the excess amount through the customer refunds workflow.
Both approaches are tracked on the customer record for full visibility. Choose based on whether the customer expects ongoing charges (credit on account) or a one-time return of funds (refund). DualEntry can automatically match incoming bank transactions to open invoices based on amount, reference number, and customer. When a match is found during bank reconciliation, DualEntry suggests the matching payment for your confirmation. If the bank match AI feature is enabled, the system uses machine learning to improve match accuracy over time. For payments that do not match automatically, the reconciliation queue presents them for manual review with suggested customer and invoice matches.

Customer Refunds

When you need to return money to a customer - for a cancelled order, returned goods, or overpayment - record a refund through /public/v2/customer-refunds/. The refund debits accounts receivable (or the customer credit balance) and credits the bank account. Refunds link back to the original payment or credit memo for audit trail purposes. You can issue a full or partial refund. Refunded invoices update their balance accordingly. If the refund relates to a credit memo rather than a direct payment reversal, apply the credit memo first and then issue the refund against the customer’s credit balance. This two-step process ensures both the revenue reversal and the cash disbursement are recorded as separate, auditable transactions.

Cash Sales

For transactions where payment is received at the point of sale with no outstanding receivable, use cash sales at /public/v2/cash-sales/. Cash sales debit the bank account and credit revenue directly, bypassing the invoice-and-payment cycle. They are useful for retail transactions, walk-in payments, and other immediate-collection scenarios. Cash sales post immediately and appear in bank reconciliation alongside your other deposit activity. Because they skip the receivable, they do not appear in aging reports. If you need to track a receivable - even briefly - use the standard invoice and payment workflow instead.
Cash sales do not create an accounts receivable balance. If you later need to issue a refund against a cash sale, use /public/v2/customer-refunds/ referencing the cash sale record rather than the invoice-based refund flow.
Last modified on May 28, 2026