> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Payments > Cash receipts, disbursements, and credit or debit memos — the posted transactions that settle AR and AP. 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](/docs/reference/invoices.md#settling-an-invoice). See [Invoices](/docs/reference/invoices.md) for the invoice-side view. NOTE A payment is a transaction record, not an invoice field. Create the payment, stage its invoice applications, and post it. **Paid** is a derived invoice status based on posted settlements. ## 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). | Field | What it is | | - | - | | `paymentType` | **Receipt** (AR, money in) or **Disbursement** (AP, money out) | | `customerId` / `supplierId` / `employeeId` | Exactly one party. Normally a Receipt is from a customer and a Disbursement to a supplier; a refund reverses that | | `bankAccount` | The GL account the cash moves through (**Bank / Cash Account** on the form) | | `totalAmount` | Cash amount. **May be zero** — see pure credit-application below | | `currencyCode`, `exchangeRate` | The payment's currency and its rate to base currency | | `reference`, `memo` | Free-text reference and note | 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: | Party + direction | Effect | | - | - | | Customer + **Credit** | AR down (a return or allowance to the customer) | | Customer + **Debit** | AR up (an additional charge) | | Supplier + **Debit** | AP down (a credit the supplier owes you) | | Supplier + **Credit** | AP up (an additional amount you owe) | 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**. FieldType
**source**`payment XOR memo` Exactly one of a `paymentId` (cash) or a `memoId` (memo) funds the settlement.
**sourcePaymentId**`payment` A *prior* posted payment supplying on-account credit. `NULL` means the row is funded by the applying payment's own cash. Either way `paymentId` stays the applying and voiding owner, so a credit-funded row can only sit on a cash payment, never on a memo.
**target**`one of three` Exactly one of a sales invoice, a purchase invoice, or a memo. (A balance-increasing memo is itself an open item, settled by targeting it.)
**sourceAmount** Principal consumed **in the funding source's document currency**, stored independently of `appliedAmount`.
**appliedAmount** Target-document principal relieved, **in company base currency**.
**discountAmount** An early-payment discount you're granting, in **base currency**. **Cash payments only** — a memo-sourced settlement can't carry one.
**writeOffAmount** A remainder you're forgiving to the write-off account, in **base currency**. **Cash payments only.**
**fxGainLossAmount** The realized FX this one application books, in **base currency**: positive is a gain, negative a loss. Server-calculated at posting, never entered.
**appliedDate** When the application takes effect.
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). NOTE Settlements are **staged while their source is Draft** and only go live when it posts. This includes a memo-sourced "apply credit" made through a payment: even though the memo itself is posted, its credit application is tied to the payment applying it and doesn't count until *that* payment posts — so the composer stays consistent with cash applications. ## 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.
**Draft** The document is being composed. You edit the amount, party, and staged applications, and you can delete it outright. Nothing has hit the ledger.
**Posted** The GL journal is written and the settlements go live. Applications are frozen — to change how a posted payment lands, void it and re-enter it.
**Voided** A reversing (mirror-image) journal is written and the document is closed. It can't be edited or reused.
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](/docs/reference/accounting.md)), 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](/docs/reference/accounting.md) 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 customer deposit. On a **"Payment from Customer"**, pick one of that customer's open sales orders or Draft or Active [rental agreements](/docs/reference/rental-agreements.md#deposits) 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. Alforse screenshot**Payment from Customer form with the Deposit for picker open, listing the customer's open sales orders and rental agreements** Deposit for narrows to the selected customer's open documents. GOOD TO KNOW Alforse forgives **dust**. When settlements leave a balance under one cent — smaller than the currency can represent — the invoice reads fully **Paid** rather than sitting a fraction of a cent short. ## 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. ## Related **Invoices** The open items a payment or memo settles, and settlement from the invoice's angle. [Open](/docs/reference/invoices.md) **Accounting** Where a posted payment or memo's ledger entries land. [Open](/docs/reference/accounting.md) **Customers & suppliers** The parties a payment or memo is drawn against. [Open](/docs/reference/suppliers-and-customers.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.