> ## Documentation Index > Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt > Use this file to discover all available pages before exploring further. # Payments & Receipts > Record money coming in (receipts from customers) and money going out (payments to vendors), allocate that money against the invoices or bills it settles,… Record money coming **in** (receipts from customers) and money going **out** (payments to vendors), allocate that money against the invoices or bills it settles, take deductions such as withholding tax or bank charges, and turn any leftover balance into an advance. **You'll find this at:** `/accounting/payments` — in the navigation this page is labelled **Payments** ("Record and track payments"). In the Hitaji 360 chart of money flows, a payment with type **Receipt** is "Money In" and a payment with type **Payment** is "Money Out". The same screen handles both — you choose the direction when you create the record. > 📷 *Screenshot: The Payments list page with the "New Payment" button and the Money In / Money Out toggle — to be added.* *** ## Who can do what (permissions) Each action is gated by its own permission slug: | Action | Permission slug | | -------------------------------- | ----------------------------- | | View payments | `accounting-payments:read` | | Create a payment | `accounting-payments:create` | | Edit a draft payment | `accounting-payments:update` | | Delete a draft payment | `accounting-payments:delete` | | Post a payment | `accounting-payments:post` | | Reverse a posted payment | `accounting-payments:reverse` | | Email a receipt | `accounting-payments:send` | | Allocate / re-allocate a payment | `accounting-payments:update` | If a button is missing for you, you most likely lack the matching permission — ask your administrator. *** ## The life of a payment A payment moves through three statuses: 1. **Draft** — created but not yet in the ledger. You can freely edit, re-allocate, or delete it. Nothing has hit the General Ledger (GL) yet. 2. **Posted** — the journal entry has been written to the GL and the linked invoices/bills have had their balances reduced. A posted payment **cannot** be edited or deleted — you must reverse it instead. 3. **Void** — a previously-posted payment that has been reversed. Its GL effect and its effect on invoice/bill balances have both been undone. *** ## Recording incoming money (a Receipt) **When:** a customer pays you — against one or more sales invoices, against a non-sale debt, or simply on account (money received before you know what it settles). ### Steps 1. Go to **Payments** (`/accounting/payments`) and click **New Payment**. 2. Set the direction to **Money In** (type = Receipt). 3. Fill in the fields: | Field | What to enter | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Reference number** | Optional. If you leave it blank the system generates one automatically with an `RCP` prefix (receipts) — e.g. `RCP-0001`. | | **Contact** | The customer who paid. Optional, but required if you want to allocate against their invoices or email them a receipt. | | **Payment date** | The date the money was received. | | **Amount** | The total received (must be greater than 0, two decimal places). | | **Currency** | Defaults to `UGX`. | | **Deposit-to account** | The bank or cash account the money landed in. This **must be an asset account** that belongs to the current book — see "The deposit-to account" below. | | **Payment method** | One of: cash, check, bank transfer, card, mobile money, other. | | **Description** | Free-text note (up to 500 characters). | | **Allocations** | Optional at this stage — which invoices the money settles (see "Allocating a payment" below). | 4. Save. The receipt is created as a **Draft**. 5. When you're ready, **Post** it (see "Posting"). ### Behind the scenes (Receipt) When you post a receipt, Hitaji 360 writes this journal entry: * **Debit** your bank / cash account for the **net cash** received (amount minus any deductions). * **Debit** each deduction account for its amount (e.g. the bank-charge expense account). * **Credit** Accounts Receivable for the **full payment amount**. In plain English: the bank balance goes up by what actually arrived, any fees or withholding are booked to their own accounts, and the customer's receivable is reduced by the full amount they were credited with. > If the receipt settles a **non-sale debt** (money lent, paid-on-behalf, etc.), the receivable credit is automatically split so it lands on that debt's own sub-ledger (Loans Receivable / Other Receivable) rather than trade Accounts Receivable. When every allocation is an ordinary sales invoice, it collapses to a single Accounts Receivable credit. *** ## Recording outgoing money (a Payment) **When:** you pay a vendor — against one or more bills, or on account. ### Steps The steps mirror a receipt, but you set the direction to **Money Out** (type = Payment): * The auto-generated reference uses a `PMT` prefix (e.g. `PMT-0001`). * The **Contact** is the vendor you're paying. * The **Deposit-to account** is the bank/cash account the money is leaving from. * Allocations target **bills** (or legacy expenses) rather than invoices. ### Behind the scenes (Payment) When you post a vendor payment, Hitaji 360 writes: * **Debit** Accounts Payable for the **full payment amount** (your liability to the vendor goes down). * **Credit** each deduction account for its amount. * **Credit** your bank / cash account for the **net cash** that actually left. *** ## The deposit-to account The **deposit-to account** is the bank or cash account money lands in (receipt) or leaves from (payment). Hitaji 360 validates that the account you pick: * is an **asset** account, and * belongs to the **current accounting book**. If it isn't, you'll see "Invalid bank/cash account". Group accounts and non-bank accounts can't be used here. *** ## Allocating a payment across invoices or bills Allocation is how you tell Hitaji 360 which documents a payment settles. A single payment can be split across several invoices/bills, and you don't have to allocate the whole amount — any unallocated remainder sits "on account". ### Finding what's outstanding From a payment you can pull the party's outstanding documents (the **Get outstanding** action). It lists, oldest first (FIFO by document date): * For a **Receipt**: the customer's outstanding **invoices**. * For a **Payment**: the vendor's outstanding **bills**. Each row shows the document number, date, total, how much is already allocated, the outstanding balance, the due date, and how many days old it is. ### Allocation rules Each allocation row must target **exactly one** of: an invoice, a bill, or an expense — never more than one. The system enforces: * **Total allocated ≤ payment amount.** You can't allocate more than you received/paid. * **Per-invoice allocation ≤ that invoice's outstanding balance.** You can't over-pay an invoice. * **The invoice must be payable** — its status must be Sent, Partially Paid, or Overdue. You can't allocate against a draft or approved-but-unsent invoice ("Invoice must be sent first"). * **The payment date can't be earlier than the invoice's issue date** — a receipt collected before the customer was even invoiced is rejected (compared by calendar day). ### Re-allocating (the Allocate action) The **Allocate** action **replaces** a payment's allocations and deductions wholesale (it is not an append). When you save it, the system re-checks the sum invariant: > Σ allocations + Σ deductions **≤** payment amount If you re-allocate a payment that is **already posted**, Hitaji 360 doesn't just rewrite the numbers — it posts a balancing **payment-reconciliation** journal entry so the GL stays in step with the new allocation picture, and updates each affected invoice/bill balance by the difference. See [Payment reconciliation](/accounting/user/transactions/payment-reconciliation). ### What allocation does to the invoice/bill When the payment posts (or when a posted payment is re-allocated), each linked invoice or bill has its **amount paid** increased and its **balance due** decreased. Its status is recalculated automatically: * Fully covered → **Paid** * Partly covered → **Partially Paid** * Back to zero (on reversal) → Overdue / Sent / Approved as appropriate > 📷 *Screenshot: The allocation panel showing outstanding invoices with amounts being applied — to be added.* *** ## Deductions & withholding on a payment A **deduction** is an amount that reduces the net cash moving on the payment even though the customer/vendor is credited/debited for the gross. Use deductions for withholding tax (WHT), bank charges, early-payment discounts, and similar. Deduction types: | Type | Use it for | | -------------------------- | ----------------------------------------------------------------------------------------------------------- | | **Withholding** | Withholding tax retained on the payment. **Requires a withholding code** — you'll get an error without one. | | **Bank charge** | Bank fees deducted from the transfer. | | **Early payment discount** | A discount taken for paying early. | | **Other** | Anything else. | Each deduction row carries an **amount**, an **offset account** (where the GL leg lands), and an optional **memo**. ### Behind the scenes (deductions) Deductions change the cash leg of the journal entry: * On a **receipt**, each deduction is an extra **debit** (e.g. bank-charge expense), and the bank is debited only for the **net** of (amount − deductions). The customer is still credited the full amount. * On a **payment**, each deduction is an extra **credit**, and the bank is credited only for the net. Withholding deductions additionally update the party's **withholding balances** for the fiscal year, so WHT certificates and reports stay accurate. The total withholding on a payment is cached on the payment record. > The sum invariant covers deductions too: allocations **plus** deductions can't exceed the payment amount. If deductions alone exceed the amount you'll see "Payment deductions exceed payment amount". *** ## Posting a payment Posting is what turns a draft into a ledger fact. 1. Open the draft payment. 2. Click **Post**. (Optionally, the post action can email a receipt — see "Receipts by email" below.) On post, Hitaji 360: * Re-validates every per-invoice allocation against the invoice's **current** outstanding balance (in case another draft consumed the balance in the meantime). * Writes the journal entry described above. * Updates each linked invoice/bill's paid amount, balance, and status. * Records a timeline event. Posting is **idempotent** — if the same post request is retried (e.g. a flaky connection), it resolves to a single journal entry rather than double-posting. *** ## Turning leftover money into an advance If a posted payment has an **unallocated balance** (money received/paid that isn't tied to any invoice/bill), you can convert it into an advance with the **Create advance** action. * Only **posted** payments with an unallocated balance can do this, and only once per payment. * For a **receipt**, this reclassifies the unallocated amount as a **customer deposit**: Debit Accounts Receivable / Credit Customer Deposits. * For a **payment**, it books a **staff/vendor advance asset**: Debit Staff Advances / Credit Accounts Payable. The created advance is linked back to the payment so you can trace it later. *** ## Reversing a posted payment To undo a posted payment, use **Reverse** (requires `accounting-payments:reverse`): * The original journal entry is reversed. * Every invoice/bill allocation is rolled back (paid amounts go back up to outstanding, statuses recalculated). * The payment moves to **Void**. * If the payment had created an advance, that advance is voided too — **unless** the advance has already been reconciled against an expense claim, in which case the reversal is blocked with a clear message. To delete instead: only **draft** payments can be deleted; a posted payment must be reversed first. *** ## Receipts by email & PDF For receipts (Money In), Hitaji 360 can email the customer a PDF receipt: * The **Post** action can send the receipt automatically (subject to the book's auto-send setting). * The **Send receipt** action (requires `accounting-payments:send`) emails it on demand. If the contact has no email address, it reports "No contact email — receipt not sent". * A **PDF** of any payment receipt can be downloaded at any time. The system records whether the receipt was sent, failed, or skipped (and why — e.g. no email, cash counter receipt, or a back-dated payment older than 3 days), so the UI can show a status pill and a Resend option. > 📷 *Screenshot: A payment detail page showing the receipt status pill and the Reverse / Send receipt actions — to be added.* *** ## Working across multiple businesses Payments belong to an **accounting book**, and each business you operate has its own book. The book is carried on every request as the `workspaceId`. Before recording a payment, make sure you're working in the correct business/book — a deposit-to account, a customer, and an invoice are all scoped to one book, and you can only allocate a payment to documents in the same book. *** ## Related * [Payment reconciliation](/accounting/user/transactions/payment-reconciliation) — match unallocated payments to outstanding invoices in bulk. * [Bank reconciliation](/accounting/user/transactions/bank-reconciliation) — match your bank statement against the ledger. * [Debts (money lent / other receivables)](/accounting/user/transactions/debts) — non-sale money owed to you, cleared through this same payment path. * [Bank loans](/accounting/user/transactions/bank-loans) — loans you've taken and their repayments.