Approve invoice-level offsets between a customer and supplier account, protect the remaining cash payment, and prove that both ledgers reflect the same settlement.
Your company owes a supplier $12,000. The same business owes you $7,500 for a separate sale. Sending $4,500 might look like the obvious answer—but a subtraction alone does not settle either account correctly.
A customer-vendor netting process connects an authorized offset to specific open invoices on both sides, then controls the remaining payment or receipt. The output is a settlement packet that AP, AR, treasury and accounting can all trace, not just a smaller bank transfer.
This guide proposes company operating controls for one legal entity trading with the same external legal counterparty in one currency. Confirm the arrangement’s legal and contractual basis with the responsible reviewer. It does not establish a right to set off debts, prescribe tax treatment, or address financial-statement offsetting.
Define the settlement before calculating the difference
Netting is not a supplier credit memo. A supplier credit adjusts a purchase-side obligation; a customer receivable can arise from a separate valid sale. Do not cancel either original invoice simply to make the balances agree. Use the vendor credit memo process when the issue is an actual supplier credit.
Microsoft’s customer and vendor netting documentation describes settling balances where the customer and vendor are the same party. Its Dynamics 365 implementation uses an active agreement linking customer and vendor accounts. Treat that as a system example, not proof that every business may net every balance.
Before selecting invoices, record:
- Parties: your legal entity, the counterparty’s legal identity, and the corresponding customer/vendor account IDs. A shared brand name is not enough.
- Authority: the reviewed agreement or other approved basis, scope, effective period and responsible legal/contract reviewer.
- Population: currency, cutoff time, eligible transaction types, due dates, approved adjustments and exclusions.
- Execution: who approves the invoice allocation, who posts settlement records, and who releases or collects the residual cash.
Oracle’s netting agreement guidance makes trading partners and eligible transaction types explicit business rules. Your control packet should be equally specific. Similar account names or a matching total are not an adequate scope definition.
Build one packet with two invoice populations
Give each proposed settlement a unique reference and version. Preserve the source extracts and their timestamps. Keep the full AP and AR populations visible, including excluded items, so an approver can distinguish “not selected” from “missing.”
For each invoice, record the ledger side, account ID, invoice reference, currency, original amount, prior applications, current open amount, proposed offset, remaining open amount, eligibility decision and evidence reference. Add the agreement reference, preparer, reviewer, posting date, system settlement references and residual payment or collection reference at packet level.
Use the following state matrix as a recommended operating design. The accounting owner must map it to the ERP’s actual settlement and posting functions.
| State and owner | Required evidence and control | Next state or exception |
|---|---|---|
| Scoped — AP and AR owners | Approved arrangement, legal identities, account pair, currency and cutoff. Identify affected payment proposals and collection activity. | Unclear party or authority: send for review before selecting an offset. |
| Prepared — settlement preparer | Both open-item extracts, invoice eligibility decisions and proposed allocations. Confirm no selected amount was already paid or applied. | Dispute, credit in progress or uncertain payment: exclude and assign an owner. |
| Approved — delegated finance reviewer | Exact version, totals, allocation order, exceptions and residual direction. Separate preparation from approval. | Any changed selected item or amount returns the packet for review. |
| Posted — accounting operator | Supported ERP settlement records and posting references for both sides, under approved accounting policy. | One-sided posting or unknown outcome: investigate; do not submit another settlement blindly. |
| Residual released — treasury or AR | Updated open balances, approved residual instruction and duplicate check against existing payment/collection activity. | Mismatch with approved packet: stop release and reconcile. |
| Reconciled — independent reviewer | AP and AR applications, relevant clearing records, bank evidence for residual cash and counterparty settlement advice. | Close only when allocations and remaining balances agree; retain unresolved items separately. |
A tracker is not a payment block. Where a proposal already exists, use the payment system’s supported hold or removal process and confirm the result. Coordinate with AR as well: a collection request for an amount already being offset can create another exception.
Calculate the offset from eligible open amounts
For this simple same-currency case, the proposed offset cannot exceed the smaller of the eligible AP and AR totals. That arithmetic is a limit, not authorization: the approved arrangement and selected invoice allocation still govern what may be settled.
Illustrative transaction—not a customer case: AP has two approved invoices totaling $12,000. AR has $8,500 open, but $1,000 is disputed and excluded from this settlement. The reviewers approve the remaining $7,500 for netting and the invoice allocation shown below.
| Invoice | Open before | Approved offset | Open after offset |
|---|---|---|---|
| AP invoice P1 | $8,000 | $7,500 | $500 payable |
| AP invoice P2 | $4,000 | $0 | $4,000 payable |
| AR invoice R1 | $5,000 | $5,000 | $0 |
| AR invoice R2 | $2,500 | $2,500 | $0 |
| AR invoice R3 — disputed, excluded | $1,000 | $0 | $1,000 receivable |
The approved offset is $7,500 on each side. The remaining cash payable is $4,500: $500 for P1 plus $4,000 for P2. R3 remains a separate $1,000 receivable with its dispute owner. It is not silently written off or included in the cash subtraction.
The reconciliation bridge is:
- AP: $12,000 opening balance − $7,500 offset − $4,500 residual payment = $0 remaining after that payment settles and is applied.
- AR: $8,500 opening balance − $7,500 offset = $1,000 still open.
- Noncash settlement: AP offset applications of $7,500 equal AR offset applications of $7,500.
If AP starts with a $12,000 payment proposal, do not release it alongside the offset. Rebuild or amend it through the supported controls so only the authorized residual is released. In Dynamics 365, Microsoft specifically documents netting before payment-journal creation and excludes transactions already in a payment journal from that netting function; confirm the equivalent boundary in your system.
Reconcile settlement records, not only the bank line
The bank statement will show the $4,500 residual payment, not the entire $12,000 AP settlement. Accounting needs both the noncash application records and the cash application to explain the result.
Oracle’s Netting Settlement Listing distinguishes original open, netted and remaining amounts on both ledger sides. Use that before-and-after logic even when your ERP uses different reports.
- Match the posted offset to the approved packet version, by invoice and currency.
- Confirm both AP and AR applications exist and total the same offset amount.
- Reconcile any netting/clearing account used by your configured posting method. Explain differences rather than forcing a balance.
- Match the residual payment or receipt to bank evidence and the intended remaining invoices.
- Send or retain settlement advice identifying the invoices, amounts offset, residual cash and items still open. Record any counterparty disagreement.
Posting mechanics vary. Microsoft’s guidance on multiple customer/vendor records in one voucher documents settlement problems and an alternative using separate vouchers through a clearing account. Do not copy journal entries from a generic example into a different configuration. Have accounting validate the supported method and period treatment.
This complements the broader accounts payable reconciliation process: the packet explains this offset, while AP close still needs a complete subledger-to-ledger reconciliation.
Make changed or failed settlements recoverable
An invoice changes after approval
Freeze the affected residual instruction, preserve the old packet and recalculate from current open items. A new credit, partial receipt or dispute can change both eligibility and the cash direction. Require approval of the revised allocation before proceeding.
Only one ledger side appears settled
Keep the case open and establish whether processing failed, remains pending or posted under another reference. Do not post an unrelated credit just to remove an aging item. Accounting should use the supported completion or reversal route, then reperform the two-sided reconciliation.
The offset must be reversed
Record the reason, affected invoices, original settlement and residual cash status. Obtain approval and confirm which balances the system reopens. A reversal does not undo a bank transfer. Any recovery or new payment needs its own reviewed instruction linked to the original case.
Where Workhint fits
The cross-team work begins before ERP settlement: AP and AR must supply evidence, a reviewer must approve the same packet, and accounting must receive the approved handoff. Workhint’s Workflow Engine describes required details and files, plus approvals routed to defined roles. Those building blocks are relevant to organizing that review.
The Finance Leaders solution describes payment review and approval with connected finance records. Evaluate those handoffs for your settlement process, while keeping legal eligibility, ledger posting, bank controls and reconciliation decisions with their accountable owners.
These pages do not establish a native AP/AR netting engine, an ERP integration or an automatic bank-payment block. Confirm the actual configuration and system boundaries before relying on them.
FAQ
Can we net accounts just because the names match?
No. Verify legal identities, the approved arrangement and eligible invoices. Related companies or trading names are not automatically the same counterparty.
Does netting mean issuing a supplier credit?
Not necessarily. The original purchase and sale can both remain valid. Use the supported settlement records; accounting determines the correct documents and entries rather than inventing a commercial credit.
When is the netting case complete?
When the approved offset is applied on both sides, the residual cash is reconciled, relevant clearing records agree, and remaining excluded items have explicit owners and balances. “Payment sent” alone does not prove that result.
Leave a Reply