The legacy settlement link: one row nets a payment or credit document against an open document and carries the amount applied. It is explicitly the predecessor of the OpenTransaction + SettlementAllocation open-item engine (see docs/finance/finance-accounting-module-plan.md D6/D8) and is retained only because live code still writes it — new settlement work belongs on SettlementAllocation, which posts a journal so the GL and the open items cannot disagree. PaymentAdjustment does NOT post to the ledger. Its behaviour is also narrower than its column list suggests: PaymentAdjustmentHandler applies a saved row to Invoice, Order and ExpenseVoucher only, and its validation counts just OrderId, InvoiceId and PaymentId, so rows keyed solely on BillId, PurchaseOrderId, CreditNoteId or DebitNoteId are rejected as an invalid combination even though the columns exist.
Fields
| Field | Label | Type | Required | What it does |
AdjustmentAmount | Adjustment Amount | Currency | | The amount applied by this settlement link. On the invoice path it is validated not to exceed the invoice's current OpenAmount and is then ADDED to the invoice's AdjustedAmount, so the adjustment reduces what remains open. |
BillId | Bill | Lookup → Bill | | The supplier bill being settled. As with the note columns, the save-time application covers Invoice, Order and ExpenseVoucher only and the validation rule does not count this column, so a bill-keyed row records the intent without moving the bill's balance. |
CreatedById | Created By | Lookup → UserAccount | Yes | |
CreatedDateTime | Created Date | DateAndTime | Yes | |
CreditNoteId | Credit Note | Lookup → CreditNote | | The credit note supplying the credit being applied. Written by the claim-settlement path, which nets a credit note against the partner's open invoices oldest-first and records one row per invoice. Note that the generic save-time application does not act on this column, and the two-document validation rule does not count it — reading a credit note's consumption is safer from the note's own AdjustedAmount/OpenAmount. |
DebitNoteId | Debit Note | Lookup → DebitNote | | The debit note involved in the settlement. The column exists, but the handler's save-time application covers only Invoice, Order and ExpenseVoucher, and the validation rule does not count this column — so a debit-note-keyed row does not move any balance by itself. |
DocumentDate | Document Date | Date | | |
ExpenseVoucherId | Expense Voucher | Lookup → ExpenseVoucher | | |
ExternalId | External | Text | | |
Id | Id | Guid | Yes | |
InvoiceId | Invoice | Lookup → Invoice | | The customer invoice being settled. This is the best-supported path: on save, the handler loads the invoice and adds the adjustment to its AdjustedAmount, refusing an amount larger than the invoice's open balance. |
ModifiedById | Modified By | Lookup → UserAccount | Yes | |
Name | Name | Text | Yes | |
OrderId | Order | Lookup → Order | | The sales order being settled — an advance or on-account application against an order rather than an invoice. Applied on save by the order service, and counted by the two-document validation rule. |
OwnerId | Owner | Lookup → UserAccount | Yes | |
PartnerAccountId | Account | Lookup → Account | | The party the settlement belongs to (labelled simply "Account"). Copied from the source document when the claim engine writes the row; it scopes the adjustment for partner-level reporting. |
PaymentId | Payment | Lookup → Payment | | The payment or receipt doing the settling. Validation counts documents across OrderId, InvoiceId and PaymentId and requires exactly two of them, and rejects an Order-only or Invoice-only row — so in practice a row pairs the payment with an order or an invoice, or pairs an order with an invoice. |
PurchaseOrderId | Purchase Order | Lookup → PurchaseOrder | | |
RecordTypeId | Record Type | Guid, hidden | | |
UIProps | UI Props | Text | | |
UpdatedDateTime | Modified Date | DateAndTime | Yes | |
Actions
| Action | Label | Type | What it does |
Clone | Clone | ServerAction (Clone) | Create a copy of this record |
New | New | New | New |