---

When Trial Balance Matches but Accounts Payable Doesn’t: A Real ERPNext Troubleshooting Story

Reconciling financial reports in ERPNext can be deceptively tricky. Sometimes the Trial Balance and General Ledger look correct, yet the Accounts Payable (AP) report is off. This article walks through a real-world troubleshooting case that explains why this happens, how to identify it, and how to prevent it in the future.

---

The Symptom

• Trial Balance showed correct balances.
• General Ledger (GL) totals for the payable account were correct.
• Accounts Payable report did not match the payable balance.
• The difference was small but persistent — and only affected AP.

At first glance, this looks like a reporting bug. It wasn’t.

---

Step 1: Understand How ERPNext Builds These Reports

The key insight is that not all accounting reports in ERPNext are built the same way.

Trial Balance & General Ledger

• These are account-centric.
• They aggregate data from tabGL Entry primarily by account.
• Party information (party_type, party) is optional for inclusion.

If a GL Entry hits the Payable account, it will appear here — even if no party is tagged.

Accounts Payable Report

• This is party-centric.

• It expects:

  • party_type = Supplier
  • party = Supplier Name
• Entries posted to a Payable account without party tagging are ignored.

This difference is fundamental — and often misunderstood.

---

Step 2: Compare GL Groupings Strategically

The breakthrough came from comparing the General Ledger report grouped in different ways:

1. Grouped by Voucher

   • Shows the full accounting impact of each transaction.
   • All debit and credit lines are visible.

2. Grouped by Party

   • Shows only GL lines linked to a party.
   • Any untagged payable entries disappear or fall into “blank”.

When these two views didn’t reconcile, it signaled that some payable entries were missing party tags.

---

Step 3: Identify the Culprit Transaction

Drilling down into the mismatched vouchers revealed the root cause:

• A Journal Entry posted as a contra entry

• One side:

  • Posted to a Payable account
  • No party_type or party specified

• Other side:

  • Correctly tagged with party_type and party

Result:

• The payable account balance moved (so TB and GL looked fine)
• But the supplier subledger did not, because AP reports ignore untagged entries

This single transaction explained the entire discrepancy.

---

Why This Is Easy to Miss

• ERPNext allows posting to Payable accounts without enforcing party tagging
• Trial Balance and GL don’t flag the issue
• The problem only surfaces when reconciling against AP / AR reports
• Contra and adjustment Journal Entries are the most common source

In other words: the data was technically valid, but semantically incomplete.

---

The Fix

There are two safe approaches:

1. Reverse and repost the Journal Entry

   • Ensure the Payable line has:

     • party_type = Supplier
     • party = Correct Supplier

2. (If allowed) Correct the GL Entry

   • Only advisable if your accounting controls permit direct fixes

After correcting the party tagging, the Accounts Payable report immediately reconciled with the Trial Balance.

---

How to Prevent This Going Forward

1. Enforce Party Tagging on Control Accounts

Add validation so that:

• If an account is of type Payable or Receivable
• Then party_type and party must be mandatory

This can be done via:

• Server-side validation
• Custom scripts
• Accounting policy + training

2. Periodic Audit Query

Regularly check for payable GL entries without party tagging:

• Payable account
• party IS NULL OR party = ''

This catches issues early — before month-end close.

---

Key Takeaways

• Trial Balance ≠ Subledger
• GL correctness does not guarantee AP/AR correctness

• Always reconcile:

  • Account balance vs
  • Party-based reports
• Grouping the GL by voucher vs party is one of the fastest diagnostic techniques in ERPNext

---

Final Thought

This wasn’t a software bug — it was a data integrity gap that only appears when you understand how ERPNext’s reporting layers differ. Once you know where to look, these issues become easy to diagnose — and even easier to prevent.

If this story saves you a few hours of debugging during month-end, it’s done its job.