Skip to main content
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: 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:
  1. Save. The receipt is created as a Draft.
  2. 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.

​
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: 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.