Skip to main content
A payment is a posted cash transaction that settles receivables or payables. A Receipt records incoming cash; a Disbursement records outgoing cash. A credit or debit memo adjusts a balance without moving cash. Payments and memos are independent documents with separate lifecycles, but both apply to invoices through an invoice settlement. See Invoices for the invoice-side view.

​
Payments

A payment carries a party, a bank or cash account, a date, a currency, an exchange rate, and a total. Exactly one counterparty is set: a customer, a supplier, or an employee (an employee payee settles reimbursements only), never more than one. Direction and party are deliberately decoupled so refunds work: a Disbursement can pay a customer (refunding an AR credit) and a Receipt can come from a supplier (refunding an AP debit). Payments number per company from a PAY-YYYY-MM- sequence.

​
Credit and debit memos

A memo is payment-shaped but non-cash: a party, an amount, and a reason general-ledger account instead of a bank account. It’s its own document (not an invoice line). direction is whether it credits or debits the party’s control account, and the four party-by-direction combinations map cleanly to AR/AP movement: A memo belongs to exactly one party. The memo form has no reason-account field: at posting Alforse derives the account from the company’s account defaults by party side and direction (a customer Credit uses the sales-discount account, a customer Debit the sales account, a supplier Debit the supplier write-off account, a supplier Credit the service-charge account) and stamps it on the memo for the audit trail. Direction only flips which side of the entry the control and reason accounts land on. Credit and debit memos number independently, from CR-YYYY-MM- and DR-YYYY-MM- sequences.

​
The settlement row

Cash and memos both settle open items through one primitive: the invoice settlement. Each row nets one source against one target. A settlement row has to move something: either applied, discount, and write-off sum to more than zero, or the row consumes a positive sourceAmount. An AR source only settles AR targets for the same counterparty, and an AP source only settles AP targets — the posting functions enforce party and side consistency (a Receipt rejects purchase invoices, a Disbursement rejects sales invoices, and a payment can only settle its own party’s invoices).

​
Lifecycle

Payments and memos share one lifecycle. Draft is freely editable; posting books the GL entries and freezes the applications; voiding reverses. Voided is terminal.
Only a Draft can be deleted; a Posted payment or memo must be voided instead, which preserves history. Voiding is only allowed from Posted.

​
What posts to the general ledger

Posting always writes a journal and applies the settlements. While the General Ledger is disabled (see Accounting), no journal is written.
  • A payment books the bank account against the AR or AP control account (receivables for a customer, payables for a supplier), split per application. Each settlement’s discount goes to the discount account and its write-off to the write-off account. Realized FX is computed per application — the carrying value released from the funding source, less the base principal relieved on the target — and stored on that settlement row as fxGainLossAmount. The journal then books the net of those to the realized exchange gain or loss account as one line.
  • A memo books a balanced two-line entry: the control account against the derived reason account. Applying a balance-reducing memo to an invoice afterward is GL-neutral — both sit in AR/AP — and realizes no FX, because Alforse only lets you apply a credit whose exchange rate matches the invoice’s.
Every payment and memo journal line is tagged with the counterparty’s type and entity dimensions, so AR and AP can be reported by customer or supplier. Voiding emits a paired reversing journal rather than mutating the original, and carries the same dimensions so dimension-filtered balances net to zero. See Accounting & the ledger for where these entries land.

​
On-account credit and overpayment

Applying more than an invoice’s open balance is blocked per invoice — a settlement can’t exceed what’s left to collect on that invoice, and the cap counts every posted settlement against it, cash and memo alike. A payment’s cash total, though, need not equal what it applies:
  • Overpayment — when a payment’s cash exceeds the invoices it applies to, the remainder stays on the party’s account as on-account credit, ready to apply to a later invoice.
  • Pure credit-application — a payment with zero cash that only applies the party’s existing posted credits to open invoices. This is why totalAmount may be zero.
  • Applying more than cash — when applications exceed the payment’s cash, the excess draws down the party’s available on-account credit (the net unapplied cash on their other posted same-direction payments). Only same-direction payments contribute: a Receipt from a customer leaves credit, a Disbursement to the same customer consumes it. Applying more credit than the party actually has errors out.
A customer receipt can also be a . On a “Payment from Customer”, pick one of that customer’s open sales orders or Draft or Active rental agreements under “Deposit for”, and its unapplied cash posts to Customer Prepayments instead of on-account credit. It is applied like any other credit, but only to invoices of the document it was taken for. A “Refund to Customer” with “Refund deposit for” pays the balance back, and that picker also lists closed documents that still hold a deposit.

​
The AR / AP workbench

The Receivables and Payables workbenches present each side as an aged tree: counterparties at the root carrying the current and past-due aging buckets, expanding to the open documents (invoices, credit memos, debit memos) beneath them, plus any unapplied on-account credit. Each side also runs a GL tie-out that compares the subledger balance to the AR or AP control-account balance and flags any variance. Payments and memos are the transactions that move those numbers.