xMatix
Sign in Request demo
xMatix
PRODUCTS
SalesField Sales & SFACRMRewardsClaimsInventoryProcurementWarehouse 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
Auto DMSConsumer Goods DMSSales Force Automation (SFA) 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/Finance & Accounting/Payment allocations (Payment Adjustments)
CONCEPT · Last reviewed

Payment allocations (Payment Adjustments)

A payment allocation, stored as a Payment Adjustment record, says that a payment, credit note, debit note or advance settles part or all of a particular invoice, bill, order or expense voucher. It holds the amount applied. You rarely create one by hand: xMatix writes it when you apply a payment on the payment form, when you use Apply payment on an invoice or bill, and when a posting applies an advance or a credit note automatically. Every "amount paid" and "open amount" you read on those documents is built from these records.

Overview

A payment on its own only says that money moved. The allocation says what that money was for. Each allocation links two documents and carries one amount, the Adjustment Amount:

What settlesWhat it settlesTypical source
A customer receipt (Payment Taken)An invoiceThe payment form, or Apply payment on the invoice
A supplier payment (Payment Given)A bill, or an expense voucher posted on creditThe payment form, or Apply payment on the bill
A receiptA service order, as an advanceThe payment form opened from the service order
A supplier paymentA purchase order, as an advanceThe payment form
A sales credit noteAn invoiceApply payment on the invoice, or automatically when the note posts
A purchase credit (a credit note for a bill return)A billApply payment on the bill, or automatically when the note posts
A purchase debit noteA billApply payment on the bill, or automatically when the note posts

One more kind links three documents. When an invoice is raised from an order that already holds an advance, an allocation names the payment, the order and the invoice, and moves the advance from the order to the invoice. A bill raised from a purchase order with an advance gets the same kind of allocation.

A receipt taken against a sales order is different. It creates no allocation. The payment is tagged with the order and stays open on the account. Unless the Finance setting is Manual, it is applied when an invoice is raised from that order, up to the value being invoiced. Otherwise you apply it from the invoice yourself.

When to use it

You work with allocations, usually without seeing the record itself, when you:

  • apply a receipt to one or more invoices, or a supplier payment to bills;
  • use an advance or an unapplied payment that is already on the account;
  • set a credit note or debit note off against an invoice or bill;
  • check why an invoice still shows an open amount, or why a payment still shows money unapplied;
  • record the TDS a customer deducted from a receipt, invoice by invoice.

To record new money, use Recording and applying payments. To change what is owed because of a price, quantity, return or tax correction, use a credit note or debit note.

How xMatix handles it

  • Saving an allocation updates both documents at once. On the document being settled, Adjusted Amount goes up and Open Amount comes down by the allocated amount. On the payment, Adjusted Amount goes up and Open Amount, the money still unapplied, comes down.
  • Amount Paid counts payments only. An invoice's, bill's or expense voucher's Amount Paid is recalculated from its payment allocations. A credit note or debit note settles the document but is not a payment, so it reduces Open Amount without adding to Amount Paid.
  • Orders keep their advance. A receipt applied to a service order raises the order's Advance Amount and Amount Paid. A supplier payment applied to a purchase order raises the purchase order's Advance Amount. When the advance is later used by the invoice or bill raised from that order, the order's Adjusted Advance Amount goes up, and the payment is not counted a second time.
  • Service order invoices. A payment applied to an invoice that was raised from a service order also counts towards that service order's Amount Paid.
  • The ledger follows once both documents are posted. An allocation writes no journal of its own for the money applied. Once the payment (or credit note) and the document it settles are both posted, xMatix settles their open items in the AR and AP subledgers against each other, so the ageing and the party ledger agree with the documents. The order in which the two are posted doesn't matter. The later posting completes the settlement.
  • Changing or removing an allocation reverses its effect. xMatix applies the difference between the old and the new amount, and the open-item settlement is redone to match.
  • Customer TDS on a receipt. When a customer pays an invoice net of TDS, the TDS can be recorded on the allocation. Once the receipt and the invoice are both posted, xMatix posts a journal that debits TDS receivable and credits accounts receivable, dated on the receipt. It also adds the amount to the TDS register and reduces the invoice's open amount by it. What the customer actually deducted replaces any TDS estimate the invoice made itself.
  • Automatic allocations. Postings can create allocations without a user: an advance carried onto the invoice or bill raised from its order, a credit or debit note applied to the document it names, a payment created for a document paid in cash at posting, and credit notes applied by the claims settlement job. The Finance settings below control which of these happen.
  • Numbering. A new allocation is numbered from the SCN series, followed by the date and a running number.

Prerequisites

  • The documents involved belong to the same customer or supplier, and to the same company.
  • To apply anything to an invoice or bill, it must be saved and have something open. An invoice must not be cancelled.
  • Credit notes and debit notes are offered in Apply documents only once they are posted.
  • Your security profile gives you access to Payment Adjustments, and to the payments and documents you are working with (see Permissions).

Procedure

Step 1 — Apply a payment when you record it

On the payment form, select the account, enter the amount and tick the documents in Open Documents. Save creates the payment and then one allocation for each ticked invoice, bill, service order, purchase order or expense voucher. The full procedure is in Recording and applying payments.

Step 2 — Apply money that is already on the account

  1. Open the invoice or bill.
  2. On its amount card, select Apply payment. If the card shows a single button, look under More. Apply payment appears only while the document is saved and has something open.
  3. The Apply documents dialog opens. At the top it shows Open on this invoice (or bill), Selected to apply and Remaining open.
  4. The table lists, oldest first, the party's payments that still have money unapplied, then its posted credit notes, then (on a bill) its posted purchase debit notes. Each row shows Document, Type, Date, Payment mode (for payments), Document amount, Available and Apply amount. When more than one kind is listed, chips such as All documents, Credit notes and Payments filter the table.
  5. Choose how to apply:
    • Auto ticks the rows oldest first until the document is covered.
    • Manual lets you tick rows and type each Apply amount. Ticking a row fills in what is still owed after the rows already ticked.

On an invoice raised from a sales order, the payments taken against that order are already ticked.

  1. Select Apply. All the allocations are saved together, or none are. The dialog closes with "Applied to this invoice" (or "… documents applied to this invoice"), and the card's open amount and payment list refresh.

If nothing is listed, the dialog says "No unapplied payments or credit notes for this invoice's account."

Step 3 — Check what a document or payment has been applied to

  • On an invoice or bill: the payment list on the amount card shows each allocation. Each row links to the payment or credit note and shows the amount applied to this document, not the payment's full amount.
  • On a payment: the record page shows the payment form read-only, with the documents it was applied to and the amount applied to each. The payment's Adjusted Amount is the total applied and its Open Amount what is left on the account.

Step 4 — Change or remove an allocation

  1. Open the payment and select Edit.
  2. In Open Documents, change the amount applied to a document, or untick it to remove its allocation.
  3. Select Save. xMatix saves the reductions before the increases, so you can move money from one document to another in a single save. The message "Payment allocations saved (… documents changed)" confirms it.

Edit is available only while the payment is not yet posted (see Recording and applying payments). The payment form can also be configured to lock allocations that came from an integration. The standard screens offer no other way to change or remove an allocation. If a posted payment was applied to the wrong document, ask your administrator.

Step 5 — Record TDS the customer deducted

When the payment form shows the TDS / Withholding panel, select + Add TDS (or Edit). Enter the Section, Rate or TDS amount for the documents the receipt settles. The amount is stored on the allocation for that invoice, with one allocation per TDS section when several apply. TDS on the part of a receipt that stays as an advance is stored on the payment instead. Whether the panel appears depends on how the payment form is configured and on the customer's TDS setup. See TDS transactions.

Fields

These are the fields of a Payment Adjustment record, in the order of its list columns, then the other fields.

FieldWhat it meansNotes
NameThe allocation's numberSet automatically from the SCN series.
Document DateThe date of the allocationApply documents uses today's date, the payment form uses the payment date, and an automatic credit-note application uses the note's date.
PaymentThe payment or receipt that settlesEmpty on a credit-note or debit-note application.
AccountThe company whose books the allocation belongs toDespite the label, this is the company (the payment's Partner Account), not the customer or supplier. Hidden on tenants that run one company.
OrderThe sales order whose advance is being usedFilled on the allocation that moves an order advance onto its invoice.
InvoiceThe invoice being settled
Adjustment AmountThe amount appliedCan't be negative or exceed what is open on the document (see Business rules).
BillThe supplier bill being settled
Credit NoteThe credit note doing the settlingA sales credit note against an invoice, or a purchase credit against a bill.
Debit NoteThe purchase debit note doing the settlingAlways paired with a bill.
Expense VoucherThe expense voucher being paidOnly a voucher posted on credit has anything open.
Purchase OrderThe purchase order the advance was paid against
Service OrderThe service order the advance was taken against
Withheld Tax AmountTDS the customer deducted on this application of a receipt to an invoiceTaken as entered, never recalculated. Empty or 0 means nothing was withheld.
TDS SectionThe section the withheld TDS was deducted underEmpty means the amount is spread over the invoice's own TDS sections.
ExternalThe record's id in the system it was imported fromFilled by integrations. Automatic write-offs skip applications an integration wrote, and automatic credit-note application skips notes an integration wrote.

Business rules

  • Valid pairs. An allocation must name exactly two documents, or three for an advance being used by an invoice or bill. Otherwise saving fails with "Adjustment needs two documents only!". An invoice on its own, or an order, service order or purchase order without a payment, is refused with "Not a valid adjustment combination!". A debit note can only be paired with a bill.
  • Amount. "Adjustment amount cannot be negative." An increase can't exceed what is open on the document or what is left unapplied on the payment: "Allocation increase … exceeds … open amount …". Allocations saved together are checked together, so two of them can't each use the same open balance.
  • Rounding. If an allocation exceeds the open amount of an already-saved invoice, bill or expense voucher by 0.01 or less, it is trimmed to the open amount instead of being refused. The paisa stays on the payment as unapplied money.
  • Cancelled invoices. "A cancelled invoice cannot receive a payment allocation."
  • Documents paid at posting. An invoice or bill posted with Cash, Bank or Card as its posting type was paid when it posted: "This invoice was paid when it was posted (Cash / Bank / Card); there is nothing open to apply a payment or credit note to." An expense voucher gives the matching message, or "This expense voucher is not posted yet, or is already fully paid; post it first, or there is nothing open to pay." when it is on credit.
  • Reductions. Reducing or removing an allocation can't take a balance below zero: "Reversing the allocation would make … negative. Reconcile its historical allocations first." An order's advance can't be reduced below what invoices have already used: "An advance cannot be reduced below its consumed amount."
  • Credit notes. A credit note's own Adjusted Amount and Open Amount are kept from its allocations, whether or not it is posted.
  • Automatic credit-note application applies a posted note to the invoice or bill it names for the smaller of the note's open amount and the document's open amount. It is skipped when the two are already paired, when the note came from an integration, when the note or invoice is cancelled, or when they belong to different parties or companies.
  • Small residuals. When an application leaves a small open balance on a posted invoice or bill, within the write-off tolerance, xMatix can write it off automatically (see Configuration).
  • Payment-time withholding. When an allocation names a posted payment that was not imported by an integration, saving it also posts any TDS (on a supplier payment against a bill) or TCS and TDS receivable (on a receipt against an invoice) due at payment time. Each leg is posted only once per document and section, so saving the allocation again doesn't post it twice.

Example

A retailer orders 26,500.00 of spare parts from a distributor and pays an advance of 20,000.00 against the sales order. The Finance settings are at their defaults.

  1. The sales coordinator takes the payment from the sales order. The payment is tagged with the order and stays open on the retailer's account. No allocation exists yet.
  2. The goods ship, and an invoice for 26,500.00 is raised from the order. Because the setting is Same order, xMatix writes two allocations of 20,000.00 with it: one that records the payment as the order's advance, and one that applies that advance to the invoice. The invoice shows 6,500.00 open, and the payment's Open Amount is 0. The ledger settlement completes when the invoice is posted.
  3. A credit note of 500.00 is posted for a damaged part. It names the invoice, so it is applied automatically: the invoice's open amount drops to 6,000.00. Amount Paid stays at 20,000.00, because a credit note isn't a payment.
  4. The retailer transfers 5,400.00 and deducts 600.00 TDS. The cashier records the receipt from the invoice and applies 5,400.00. Their payment form shows the TDS / Withholding panel, so they enter 600.00 there. Once both are posted, the invoice reads fully settled, and 600.00 is in TDS receivable.

Training

Practice exercise

In a sandbox, post an invoice for 2,000.00 to a test customer and record a receipt of 1,500.00 from the same customer with On account selected, so nothing is applied. Then open the invoice and select Apply payment.

Expected result: Apply documents lists the receipt with 1,500.00 Available. Select Auto and Apply. The invoice's open amount becomes 500.00 and its payment list shows the receipt with 1,500.00 applied. The receipt's Open Amount is 0. Try typing 1,600.00 in Apply amount: the dialog warns that the receipt has only 1,500.00 left to apply, and Apply is disabled.

Quick reference

  • One allocation = one amount from one settling document to one document being settled.
  • Payments, credit notes, debit notes and advances all settle through allocations.
  • A sales-order receipt creates no allocation until its invoice uses it.
  • Apply payment on an invoice or bill applies money already on the account.
  • Auto applies oldest first; Manual lets you choose the rows and amounts.
  • Credit notes reduce Open Amount but not Amount Paid.
  • The ledger settlement completes once both documents are posted.
  • Change or remove allocations from the payment's Edit, which is only possible before it posts.

Permissions

Access is set per security profile under Setup → Access Control → Profiles (see Security profiles):

  • Entity Permissions: the standard System Admin, Standard User, Sales Manager, Sales Executive, Sales and Service profiles have full access to Payment Adjustments. Every application of a payment or note saves allocations, so a custom profile that applies payments needs access to Payment Adjustments as well as to Payments.
  • Actions: New is granted to System Admin, Standard User and Sales Manager. Clone is granted to System Admin, Standard User and Sales Executive.
  • Reading the payments and credit notes offered in Apply documents needs access to those entities as well. A profile that can't read credit notes still sees its payments.

The record page has no actions in its header.

Configuration

WhatWhereWhat it affects
Automatic advance applicationApply unapplied payments to new invoices and bills under Setup → Feature Hub → Finance → SettingsSame order (default) carries an order's or purchase order's advance onto the invoice or bill raised from it. Oldest first also applies the party's other unapplied money. Manual applies nothing automatically: use Apply payment, where the order's payments come pre-selected.
Automatic credit and debit note applicationApply a credit note to its invoice when it posts, same screenOn (default): a posted sales credit note is applied to the invoice it names, and a posted purchase credit or purchase debit note to the bill it names.
Payments for documents paid at postingRecord a payment for Cash / Bank / Card invoices and bills, same screenOn: posting such a document also creates a payment and its allocation, so the document reads paid. Off (default): no payment or allocation is created.
Automatic write-off of residualsWrite off small residuals automatically and Write-off tolerance, same screenWrites off what an application leaves open, up to the tolerance, when a write-off account exists.
NumberingSetup → Design Studio → Entities → Payment Adjustment → Logic → Document SettingsThe SCN series used for Name.
A list for finance usersThe standard apps have no menu entry for the All Payment Adjustments list, and the app launcher doesn't offer it in searchTo review allocations as a list, add the entity to an app (see Apps, entities and records).
Data syncIntegration mappingSyncing Payment Adjustments shows a warning. Import them only when you migrate another system's settlement history. If the payments also come in through the normal write path, xMatix creates its own allocations and the invoice would be settled twice.

Common problems

"Adjustment needs two documents only!" or "Not a valid adjustment combination!"

The allocation names the wrong number or the wrong mix of documents, usually from an import or a hand-made record. Pair a payment with one document, a credit note with one invoice or bill, or a debit note with one bill.

"Allocation increase … exceeds … open amount …"

You applied more than is still open on the document, or more than the payment has unapplied. Someone may have applied another payment meanwhile. Reopen the dialog, which reads fresh amounts every time, and reduce the amount.

"This invoice was paid when it was posted (Cash / Bank / Card) …"

The invoice or bill was posted with a Cash, Bank or Card posting type, so it was paid by its own posting. Nothing is open on it. Apply the payment to another document, or leave it on the account.

"A cancelled invoice cannot receive a payment allocation."

Apply the payment to the replacement invoice instead.

Apply payment isn't on the invoice or bill

The document isn't saved yet, has nothing open, or (for an invoice) is cancelled. If the card shows one button, look under More.

A credit note isn't offered in Apply documents

Only posted credit notes of the same customer (or supplier, for purchase credits) and company are offered, and only while something is left on them. Post the note first.

The invoice is settled but the ageing still shows it open

The ledger settlement waits until both documents are posted. Post the payment or the invoice, whichever is still unposted, and the ageing follows.

"Reversing the allocation would make … negative. Reconcile its historical allocations first."

The document's recorded balance is already lower than the allocations being removed, typically after imported history. Ask your administrator to reconcile the document's allocations before you change them.

Common questions

Why does Amount Paid differ from what the customer has settled?

Amount Paid counts money from payments only. A credit note or debit note settles the document, so Open Amount goes down, but it isn't a payment, so Amount Paid doesn't change. An invoice for 10,000.00 with a 1,000.00 credit note applied and 9,000.00 received shows Amount Paid 9,000.00 and nothing open. TDS the customer deducted also reduces the open amount without counting as paid.

What happens to a payment taken against a sales order?

It stays open on the customer's account, tagged with the order, and creates no allocation yet. With the default Same order setting, raising an invoice from the order applies the payment to it, oldest payment first, up to the value of what is invoiced. Whatever isn't used stays for the next invoice of the order, and the invoice that completes the order takes the rest. With Manual, select Apply payment on the invoice: the order's payments are ticked for you.

Can I delete an allocation?

From the standard screens, you remove an allocation by unticking the document in the payment's Edit, and only while the payment isn't posted. Removing it gives the amount back to both documents: the document's open amount goes up and the payment's unapplied amount goes up. Once both are posted, the ledger settlement is reversed too. For posted payments, ask your administrator.

Does applying a payment post a journal?

No, not for the money itself. The payment's own posting already moved the cash and the receivable or payable. The allocation links the payment's open item to the document's, so the ageing and party ledger show the document as settled. The exceptions are TDS that a customer deducted and payment-time TDS or TCS, which post their own journals.