xMatix
Sign in Request demo
xMatix
PRODUCTS
SalesField SalesCRMRewardsClaimsInventoryProcurementWarehouse ManagementField ServiceServiceSupportTelephony & MessagingFinance & AccountingPayrollExpense ManagementCommercePortalsAnalytics & ReportingData StudioMobile AppSee all products →
PLATFORM
Platform overviewApp BuilderAutomationIntegrationsSecurity & GovernanceChange ManagementDevelopers
SENSE AI
Sense AI overviewSense AssistSense ControlSense VisionAI StudioTrust & governanceIn Claude & ChatGPTUse cases
SOLUTIONS
FMCG & DistributionManufacturing & Dealer NetworksAutomotive & DealershipsPharma & HealthcareConsumer DurablesAgri-InputsBuilding MaterialsService NetworksWarehousing & 3PLFinancial AccountingERP SoftwareIndia GST ComplianceUAE VAT & e-InvoicingSaudi ZATCA & VATAll solutions →
RESOURCES
Knowledge CenterDeveloper & CLIBlogGuidesWhat is xMatix?Company facts
COMPANY
AboutCareersPartnersEventsContactAuthorsLegal
Sign in Request demo
Home/Docs/Entity Reference/Payment Adjustment — entity reference
REFERENCE · Last reviewed

Payment Adjustment — entity reference

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

FieldLabelTypeRequiredWhat it does
AdjustmentAmountAdjustment AmountCurrencyThe 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.
BillIdBillLookup → BillThe 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.
CreatedByIdCreated ByLookup → UserAccountYes
CreatedDateTimeCreated DateDateAndTimeYes
CreditNoteIdCredit NoteLookup → CreditNoteThe 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.
DebitNoteIdDebit NoteLookup → DebitNoteThe 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.
DocumentDateDocument DateDate
ExpenseVoucherIdExpense VoucherLookup → ExpenseVoucher
ExternalIdExternalText
IdIdGuidYes
InvoiceIdInvoiceLookup → InvoiceThe 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.
ModifiedByIdModified ByLookup → UserAccountYes
NameNameTextYes
OrderIdOrderLookup → OrderThe 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.
OwnerIdOwnerLookup → UserAccountYes
PartnerAccountIdAccountLookup → AccountThe 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.
PaymentIdPaymentLookup → PaymentThe 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.
PurchaseOrderIdPurchase OrderLookup → PurchaseOrder
RecordTypeIdRecord TypeGuid, hidden
UIPropsUI PropsText
UpdatedDateTimeModified DateDateAndTimeYes

Actions

ActionLabelTypeWhat it does
CloneCloneServerAction (Clone)Create a copy of this record
NewNewNewNew