Recording and applying payments

A Payment records money received or paid and can allocate that amount against eligible open documents. In the current handler, an ordinary new payment whose finance partner can be resolved is GL-approved and posted during the insert flow. There is no guaranteed clerk-records/controller-approves gap, so complete the review before saving.

Prerequisites

• The intended account must resolve to the finance partner used by posting.
• The documents to settle must already be eligible for the Open Documents query.
• Cash and other payment accounts must be mapped through the posting configuration used by the handler.
• The operator must understand the payment-mode gaps described below before choosing Bank, Cheque or Electronic Transfer.

Procedure

123456 Expand

1. 1

   Account first — it resolves the finance partner and drives the Open Documents query below.

2. 2

   Amount is the total received or paid; allocations in the grid are entered separately and should reconcile to it.

3. 3

   Mode chips — Cheque, Cash, Bank, Electronic Transfer — swap the detail fields on the right; Cash is the least ambiguous mode today.

4. 4

   Open Documents shows what can be settled — here three open orders; the grid can list orders as well as invoices.

5. 5

   Document, Adjusted and Open Amount totals track what you have allocated; Manual on the right is the allocation mode.

6. 6

   Type an allocation per selected row; zero settles nothing and a partial amount leaves the balance open.

Step 1 — Select the account and inspect the candidates

Create a Payment and select Account first. Wait for the “updated” indicator, then compare the returned document number, type, date, document amount and open amount with the remittance. The result can contain orders as well as invoices, depending on the open-transaction source. Do not allocate by age alone when the remittance identifies a specific document.

If the grid says no account context is available, stop and correct the account selection or finance-partner setup. Saving without a resolvable partner is not a substitute for a valid settlement context.

Step 2 — Enter the amount and allocations

Enter the total payment Amount. Select the intended open rows and enter an allocation amount for each. Compare Document Amount, Adjusted Amount and Open Amount before continuing. A partial allocation can leave an open balance; an allocation of zero does not settle the row.

Keep the sum of entered allocations consistent with the payment evidence. Any deliberate unapplied amount should be supported by the business process used in your deployment and verified after posting.

Step 3 — Choose the payment mode carefully

The widget offers Cheque, Cash, Bank and Electronic Transfer, but the current UI and posting code do not use one shared set of values:

• Cash posts the money side to the Cash account type and is the least ambiguous first-party mode.
• The visible Bank choice is not one of the posting handler's explicit modes; it falls through to the cash-account path. It also renders card-oriented fields. Do not use it as proof that a bank GL account will be selected.
• Electronic Transfer posts to the Bank account type, but the current widget exposes no transfer-reference input — Transaction Reference is saved empty and has to be filled on the record afterwards.
• Cheque parks the money in the Cheques-In-Hand suspense account until the cheque clears (falling back to Bank when no suspense account is configured), and the save records a linked cheque transaction (issued or received) in the cheque register; the widget writes the mode to both ModeOfPayment and the legacy PaymentMode field so that automation sees it. Verify the cheque transaction exists after saving.
• The posting handler also recognizes Card (Bank for money received, Credit Card for money paid) even though the visible selector offers Bank. Never put a full card number in documentation or support screenshots.

Until those contracts are aligned and tested, use the mode approved for the deployed tenant and verify the resulting GL account and evidence record immediately after save.

Step 4 — Review before Save

Re-check the account, direction of payment, total, selected mode and every allocation. Saving can trigger approval/posting in the same insert transaction when the finance partner resolves. After Save succeeds, open the resulting Payment and verify:

1. status and generated document number;
2. ledger direction and selected cash/bank account;
3. each allocation and remaining open balance; and
4. any cheque or transfer evidence that the chosen mode was expected to create.

If any of those differs, use the supported correction or reversal flow for the deployment. Do not create a second payment merely to make the screen look right.

Payment batches

The current Payment Batch service only exposes an aggregate-total helper; the audited code has no first-party handler, action or scheduled job that executes a bulk payment run. This guide therefore does not describe a batch procedure. Treat any tenant-specific batch screen as custom until its posting and retry behaviour is verified.

Common problems

Open Documents remains empty. Confirm the selected account resolves to the expected finance partner and that the source documents are posted and still open. The empty initial state is not evidence that there are no receivables or payables.

Bank posted to cash. The visible Bank value currently misses the posting handler's explicit cases and falls through to cash. Correct the mode contract or posting implementation before using the option operationally.

A cheque is missing from the cheque register. The register entry is created during the GL posting of a payment whose PaymentMode is Cheque; a payment created outside the standard form (an import or an integration that set only ModeOfPayment) skips it. Verify the payment itself, then fix the source rather than re-entering the cash movement.

The payment posted immediately. That is the current normal insert path when the finance partner resolves; a separate controller approval is not guaranteed.

Common questions

Can a customer make a partial payment?

The allocation model supports entering less than the open amount. Verify the source document's remaining balance after posting; do not rely solely on the unsaved grid calculation.

When does a document stop appearing as open?

When the posting and allocation state consumed by the open-transaction query shows no remaining balance. Recording an unapplied payment is not the same as settling a particular row.

Is there a review stage between Save and posting?

Not reliably in the current ordinary insert path. Review before Save and test any tenant-specific approval metadata against the actual handler behaviour.

Related topics

• AR and AP subledgers
• Banking
• Bank reconciliation
• Payment — entity reference