ERPNext common party accounting

How common party accounting in ERPNext handles customers who are also suppliers

When one counterparty is both a customer and a supplier, the finance team usually wants receivables and payables netted without posting manual journals each month. In ERPNext, common party accounting is the feature set that makes this possible. It relies on Party Links, which tie a customer and a supplier record to the same underlying party, so that invoices and payments on either side can be recognized against one shared balance. Who needs it is clear in practice: organizations that buy from and sell to the same partner, such as a distributor that also purchases raw materials from a customer, or a services firm that resells a partner's products while receiving subcontracted work from them. Before enabling anything, the team should map which counterparties truly trade both ways and confirm that each pair should be linked at all.

The mechanics depend on how the link is configured and on the ERPNext version in use. When a sales invoice or purchase invoice is submitted for a linked party, ERPNext can post an automatic journal entry that moves the amount between the receivable and payable accounts, and the team needs to confirm which accounts, company and posting behavior apply to their setup. Offsetting is not allowed in every situation, so the reader should check the conditions under which the system permits it, including currency, company and whether the documents are still outstanding. Because the exact behavior changes between releases, the reader should check the official ERPNext documentation for their specific version and test the flow on a copy of the site before relying on it at period close.

Common party accounting does not replace payment reconciliation or a formal settlement agreement. Unallocated payments, advances and credit notes still need to be matched to invoices through the reconciliation tools, and the automatic entry does not decide which open items should be offset. A written settlement agreement with the counterparty sets the amounts, dates and legal basis for netting, and the finance team should confirm with its auditors and legal advisers how that agreement is recorded and how any tax treatment applies. Plan a control check at each close: compare the netted balance with the counterparty's own statement, review the journal entries it generated, and document who approved the link and the offset.

When offsetting is allowed and which setup fits each case

This table compares three ways to configure customer and supplier netting in ERPNext, row by row for what each option posts, what staff must reconcile, the audit trail it creates, and the conditions that should block offsetting. Read the blocking conditions row alongside your agreements register, because a link that is technically possible may still be contractually or legally unsupported. The main takeaway is that a link should follow a documented agreement, not a convenience.

Factor	Link all counterparties	Link documented netting only	Keep parties separate
What it posts	Automatic journal entry on invoice submission that offsets the linked customer and supplier balances.	The same automatic entry, but only for party pairs with a recorded netting agreement.	Normal receivable and payable postings, settled through payment entries and reconciliation.
Left for manual reconciliation	Disputed amounts, timing differences and any balance no one has agreed to net.	Partial netting, invoices outside the agreement and balances that drift from agreed terms.	Settlement of each invoice pair, which grows in effort with transaction volume.
Audit evidence	Linked party list and posted offset entries, plus the approval record for each link.	Signed netting agreement on file, tied to each Party Link and its approval date.	Individual payment entries and reconciliations per invoice, the most direct trail to follow.
Main risk	Netting a balance nobody agreed to, which misstates exposure to a counterparty.	Agreement scope drifts from the link setup, so offsets post beyond what was signed.	Heavier manual work, and cash movements that hide a netting arrangement that exists in practice.
Block offsetting when	Disputed, cross-currency or cross-company balances still need a hold, even with links in place.	Balances are disputed, currencies or companies differ, or the party is over its credit limit.	Enforce credit limits and dispute holds on each invoice, since offsetting is not in use.
Best fit	Few organizations, and only where every counterparty pair is documented and reviewed together.	Organizations that trade both ways with a defined set of partners under written terms.	Parties with few mutual transactions, or where contracts or policy do not allow offsetting.
Confirm before go-live	Whether a link can be created without a second approval step in your setup.	Who owns the agreements register and how changes to links are approved and recorded.	How payment entries and reconciliation tools handle your expected settlement volume.

Setting up common party accounting in ERPNext step by step

This sequence takes a company that buys from and sells to the same counterparties from a policy decision to a verified ledger, so that netting is applied only where finance and legal have approved it. Each step closes with a check that the reader can repeat before any live party is linked.

Confirm the netting policy and legal basis
Finance and legal agree in writing which counterparties may be offset, under what contract or set-off right, and whether the netting applies to all currencies and periods. Finance owns the policy and legal confirms that the set-off is enforceable in each jurisdiction involved. The step is done when the approved party list and the governing clauses are filed with the implementation scope, so the configuration can be traced back to a signed decision. Ask your legal team to confirm the position for each entity, since the rules differ by country.
Create or review customer and supplier masters
Before linking anything, the implementation team and your master data owner review each Customer and Supplier record for the approved counterparties. They check legal name, tax identifiers, default currency, payment terms and whether duplicate records already exist for the same legal entity. Duplicates are merged or flagged at this stage because a link between two records that describe one company only works if both sides are the same legal party. The step is complete when a reviewed list shows one customer and one supplier record per approved counterparty.
Establish the party link
In the Customer and Supplier masters, the administrator creates the link between the two records for each approved counterparty using the Party Link feature. Confirm the exact menu path, the field names and the link options in the ERPNext documentation for your installed version, because the behavior of party links has changed between releases. Record which side is the primary party for each link. The check is that the link appears on both records and that a test lookup from either side returns the linked counterpart.
Confirm default accounts, company and currency
The finance lead checks the default receivable account on each Customer, the default payable account on each Supplier, and the company and transaction currency that each linked record uses. Mismatched defaults are the most common source of postings to unexpected accounts when a netting case is later processed. Confirm the account types and the parent company for every account the linked parties will touch. The step is finished when a written mapping shows each party, its receivable and payable accounts, company and currency, and the finance lead has signed off.
Run test invoices on a non-production site
The implementation team creates a test company and a set of test parties on a non-production site that mirrors the production configuration and version. They submit a sales invoice and a purchase invoice to the linked counterpart, then test a case that the policy should allow and a case the policy should block, such as a party that is not on the approved list or a mismatched currency. The test site must not be the live environment, and test data must not be migrated back. The step is complete when every test case produces the outcome the policy specifies.
Verify journal entries and ledger balances
For each test case, the finance lead opens the journal entries created on submission and checks the debit and credit lines against the expected netting result, including which account each side hits and the currency of each line. They then reconcile the test party's receivable and payable ledgers to the expected net position, using the General Ledger and the party statement. Blocked cases must show no journal entry and a visible refusal or warning. The check passes only when the expected net balance matches the ledger to the cent and every blocked case stays blocked after the test is repeated.
Document the approved configuration and sign-off
The implementation team writes down the final configuration, including the approved party list, link settings, default accounts, the test results and the version of ERPNext the results apply to. Finance and the controller sign the document, and the same checks are scheduled to repeat after each upgrade or change to party masters. The step is done when the signed record exists and the test scripts can be rerun by someone who did not build the configuration. Keep the documented evidence with your audit file so that an external auditor can trace the treatment.

What changes for accounts receivable, accounts payable and controllers

Once a customer and supplier share a Party Link, the receivable and payable sides of that relationship sit in one place, so collections work must account for amounts the party may already owe you in the other direction. Agree with your controller how netting is handled before anyone sends a demand or places a credit hold.

Dunning scope: Check whether overdue customer invoices remain open after offsetting, so reminders do not chase an amount the offset already covers.
Offset visibility: Review open supplier invoices alongside the customer's ageing before calling the customer, so the conversation reflects the net position.
Payment allocation: Record incoming receipts against the correct invoices and confirm the allocation does not move cash onto supplier balances without a decision.
Credit holds: Agree who can place or lift a hold when a supplier invoice posts and changes the customer's net exposure.
Statements: Decide whether customer statements show gross or net balances, and confirm the wording with your finance lead.

Check daily for overdue customer invoices on linked parties that also carry an open supplier balance. Check monthly that the net position for each linked party matches the agreement on file for that relationship.

Controls to plan around netting so only approved offsets post

Netting receivables against payables changes the balance a customer or supplier actually owes, so the controls around it matter as much as the configuration. The cards below cover who can link parties, who approves offsets, how agreements are recorded, what the journal entries leave behind, who can see both sides, and how links are reviewed over time.

Restrict who can create party links

A Party Link ties a customer and a supplier record together so that ERPNext can treat them as one counterparty. Limit creation and edits of these links to a small named group, typically finance leads or the controller, and keep sales and purchasing users out of that role. The risk is that an unapproved link lets invoices from one side quietly settle obligations on the other. Check the role assignments on the Party Link permission and confirm that each link has a named creator in your change records.

Separate invoicing from offset approval

The person who raises a sales or purchase invoice should not also approve the offset that nets it against the linked party. Splitting these duties means one user cannot create a receivable, create a payable, and then net them without a second look. Confirm that the users who submit sales and purchase invoices hold no approval rights for the netting step, and sample a set of offsets each period to see who prepared and who approved them.

Attach a netting agreement to the party master

Offsetting should rest on a signed agreement that states which balances may be netted, in which currency, and on what cadence. Record the agreement reference, its date and its owner on the customer and supplier masters so the basis for each offset is visible where users work. Without this, an offset may look valid in the system but have no contractual support. Ask legal to confirm the agreement terms and check that every linked party has a current reference on file.

Keep an audit trail for offset journal entries

The automatic journal entry created when an invoice is submitted against a linked party needs to be traceable to the user, the source invoice and the approval behind it. Decide how long these entries and their related version history are kept, and make sure the retention period matches your statutory and internal policy. Check that submitted entries cannot be silently altered, and that a reviewer can trace each offset back to its invoices and approver. Confirm the retention setting and the log access rules with your auditors before go-live.

Limit who sees both balances

A user who can see the receivable and the payable for the same party gains a view of the full exposure, which may be sensitive in negotiations or fraud scenarios. Use role permissions and, where needed, user permissions so that collectors see only receivables and buyers see only payables, while a small group sees both. Test each role by logging in as a representative user and confirming which reports, ledgers and party views they can open. Review these permissions whenever roles change.

Review linked parties on a schedule

Relationships change: a customer may stop buying, a supplier may be acquired, or a party may no longer have an agreement in place. Set a recurring review, for example each quarter, that lists every active link, its agreement reference, its open balances and its last offset. Remove or freeze links that no longer have support, and record the decision. Ask the finance team to confirm who owns the review and where its sign-off is stored.

What buyers ask before setting up common party accounting

How much effort does common party accounting setup take, and what drives it?

Effort depends less on the Party Link record itself than on how many counterparties play both roles and how clean their master data is. A handful of dual-role parties with tidy records is a light exercise. Effort grows with the number of pairs, the open invoices and payments on both sides, the number of companies on the site, and the currencies involved. Each pair needs a review of default accounts, payment terms and tax settings on both the customer and supplier masters before linking, because each record keeps its own configuration. Duplicate parties add work because they must be merged or confirmed first. Ask for the count of dual-role parties, the companies and currencies in scope, and the volume of open items in any quote, since these inputs move effort more than the configuration steps do.

Can our finance team configure common party accounting without a partner?

A capable ERPNext administrator with accounting knowledge can create links for a small group of parties. The configuration steps are documented in the product, so the screens are not the hard part. The harder work is designing the offsetting policy, testing posting outcomes on a staging copy of production data, documenting when offsetting is allowed, and training the people who submit invoices and payments. A partner adds the most value when the policy must cover several companies or currencies, or when custom scripts or integrations touch the same documents. Whatever you choose, confirm how your installed version creates the automatic journal entry in your own staging site before you make the decision.

What does the work need from finance and IT?

Finance owns the decisions. They must approve which parties are dual-role, define when offsetting is permitted, agree how statements and collections treat netted balances, and sign off the reconciliation of receivables and payables before and after go-live. Finance also reviews the expected journal entries for each test scenario. IT owns the environment and access. They need a staging site that mirrors production, a backup taken before any change, and a role model that limits who can create or change party links. IT also checks that scheduled reports and statement jobs still run after the change. Agree these responsibilities in writing at the start, with a named owner on each side.

How long does testing take, and what sets that duration?

Testing length is set by the number of scenarios, not by the setup itself. Each scenario needs a test case with expected results: an invoice on each side, a payment, a partial payment, a credit note, a cancelled document, a multi-currency transaction, and a multi-company case if more than one legal entity uses the parties. Finance must review each set of generated entries, so reviewer availability often sets the pace. Problems found in testing lengthen the cycle, especially when they involve custom scripts or integrations. Ask for a written test plan with the scenarios listed, the people who approve each result, and clear exit criteria, so that you can judge progress against it rather than against a calendar guess.

Can historical open balances be netted retroactively?

It may be possible, but it depends on your data and your closing position. Retroactive netting changes balances in periods that may already be closed, and closed periods or a frozen date can block changes to earlier postings. Start by checking whether prior periods are locked and whether the outstanding invoices and payments on both sides can be matched to the same party. Where history cannot be changed cleanly, many teams net going forward and document the opening position separately, with supporting schedules that finance signs off. Confirm the exact behavior on your version in staging, and agree the treatment with your auditors before posting any historical adjustment.

What changes for tax reporting and audit?

The tax calculated on each invoice and bill generally stays with that transaction, while the netting affects the receivable and payable balances that appear in the ledger. Confirm this for your jurisdiction and your tax setup with your tax adviser, including how VAT or GST returns read the entries, because the answer depends on local rules. For audit, expect the auditors to ask for the written offsetting policy, the list of dual-role parties with approval evidence, support for each netting entry, and reconciliations of receivables and payables. DeployOpen prepares systems, controls and evidence for these reviews, but independent auditors issue any audit opinion or attestation.

What should we ask a partner to include in a written quote?

Ask for a scope statement that lists the dual-role parties, the companies, currencies and periods in scope, and the environments used for testing. The quote should name each deliverable, such as the configured links, the offsetting policy, the test evidence, the reconciliation procedure and staff training. It should state assumptions about data cleanup, who signs off each phase, how change requests are priced, and what support follows go-live. DeployOpen works from fixed-scope agreements with scope, deliverables and timelines confirmed in writing before work starts, and ongoing support is available as a separate retainer. Compare any quote against the same list so the inputs are equal.

Limits to confirm in your ERPNext version and environment

Common party accounting touches receivables, payables, journal entries and reports at once, so a setting that looks local can change several outputs. The checks below cover the document types, companies, currencies, reconciliation, reporting, legal permission and custom code that determine whether netting behaves the way your finance team expects. Confirm each one against the documentation for your exact ERPNext version and on a test site before you rely on it.

Document types the link affects

Establish which documents the Party Link changes in your version: sales invoices, purchase invoices, payment entries, journal entries and credit or debit notes. Confirm whether the automatic journal entry posts on invoice submission for both sides, and whether it also applies to returns and amendments. Test a cancelled and an amended invoice, because reversal logic is where balances most often drift from what the ledger shows.

Multi-company and multi-currency behavior

Check how a Party Link behaves when the customer and supplier records sit under different companies, or when the invoices are in different transaction currencies. Confirm which company's receivable and payable accounts are offset, and how exchange differences are posted when the two sides are in different currencies. Run a test with one foreign-currency invoice on each side before you rely on the netted balance in any company report.

Payment reconciliation and payment terms

Confirm how netted amounts interact with the Payment Reconciliation tool, advances, unallocated payments and credit notes. Check whether a netted journal entry leaves invoices marked as outstanding, and whether payment terms still drive due dates and ageing on each side. A mismatch here shows up as overdue receivables for a party whose balance is already settled, which affects collections and dunning.

Reporting and tax treatment of netted balances

Confirm how the netted amounts appear in the accounts receivable, accounts payable and general ledger reports, and whether the party's gross exposure remains visible. Ask your tax adviser how the offset affects VAT, GST or withholding returns, because a tax document may need to show the gross invoice even when the cash settlement is net. Print the statement of account for a test party and compare it to the ledger before the first close.

Contractual and bank permission for netting

Automated netting is a legal and banking decision, not only a system setting. Confirm with your bank that a net settlement is permitted for the accounts involved, and review the customer and supplier contracts for set-off clauses, notice requirements and any restriction on offsetting against a prepayment or deposit. Record the answer in writing so that the configuration can be traced to the permission that justified it.

Custom scripts touching party and journal logic

Identify any client or server scripts, custom fields or custom apps that read or write party, invoice or journal entry events. Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so confirm whether your environment allows them at all. Test each script against a Party Link scenario, since a hook that alters the journal entry can break the automatic offset without raising an error.

How DeployOpen scopes and delivers common party accounting in ERPNext

DeployOpen plans, implements, customizes, tests, documents and supports ERPNext inside your own infrastructure. For a customer that is also a supplier, we start from how your receivables and payables actually net off, then configure Party Links, check the automatic journal entries and agree when offsetting is allowed before any live transactions are posted.

How we scope

Map every party that is both a customer and a supplier, and the companies and currencies each relationship touches.
Document the offsetting rules your finance team wants, including which invoices may be netted and who approves them.
Agree the written scope, deliverables and timeline before work starts, with fixed-scope engagements as the default.
Confirm which accounts, cost centers and reports must reflect the netted position for audit and management review.

How we build

Configure Party Links between customer and supplier masters and test them on a staging site first.
Submit sample sales and purchase invoices and check the automatic journal entries against the agreed accounting design.
Test reversal, cancellation and partial offsetting cases, and confirm ageing and statements show the expected balances.
Review role permissions so only authorized users can create or change party links and offsetting entries.

How we hand over

Deliver a written configuration record covering party links, accounts, permissions and the offsetting procedure.
Provide test scripts and expected results so your team can repeat the checks after upgrades or changes.
Walk finance staff through the month-end steps for reviewing netted balances and the entries they create.
Document the changes made to standard behavior so future developers can see what was customized and why.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Re-test party link behavior when you move to a new supported ERPNext release, and confirm the version with your team first.
Review the accounting treatment with your auditors or tax advisers, since DeployOpen prepares evidence but does not issue audit opinions.
Ask any quote to separate one-time configuration work from recurring support and testing effort.

ERPNext common party accounting for customers who are also suppliers