The ERPNext v15.46 Balance Sheet / P&L / Cash Flow Crash — and How to Patch Your Instance

Financial-statement regressions are the worst kind of ERP bug to find during audit fieldwork. I lead ERPNext and Frappe implementations at MithTech, a team of Frappe specialists in Bengaluru. This playbook came out of triaging exactly that situation on a client bench.

Are you affected?

Check the exact tag first:

That returns the release the app is on, not just the branch name.

If your tag is not one of the two affected releases and the reports still fail, the fault is elsewhere: check permissions, the fiscal year setup or the account tree first.

What actually broke?

The three reports share one helper, get_accounting_entries in erpnext/accounts/report/financial_statements.py. On 17 December 2024, PR #44695 made the financial statements respect User Permissions by adding the user's match conditions to the GL Entry query. In v15.46.0 the end of that helper read:

# erpnext/accounts/report/financial_statements.py (v15.46.0)
from frappe.desk.reportview import build_match_conditions

match_conditions = build_match_conditions(doctype)

if match_conditions:
    query += "and" + match_conditions   # query is still a pypika object here

query, params = query.walk()

return frappe.db.sql(query, params, as_dict=True)

query was still a query-builder object when the string was added to it. pypika reads + on a query as a set operation, so the string became the "other query" in a union, and query.walk() failed when it asked that string for its SQL:

File "apps/erpnext/erpnext/accounts/report/financial_statements.py", line 537, in get_accounting_entries
    query, params = query.walk()
...
AttributeError: 'str' object has no attribute 'get_sql'

That is the traceback in issue #44766, "After Update to v15.46.0 (version-15) - All Financial Report Can't Open". The branch only runs when build_match_conditions returns something, so it hits users whose permissions add conditions, which on most finance teams means the people who actually run the reports.

The fix, PR #44765, moves one line: turn the query into SQL first, then append the match conditions to the string.

query, params = query.walk()
match_conditions = build_match_conditions(doctype)

if match_conditions:
    query += "and" + match_conditions

return frappe.db.sql(query, params, as_dict=True)

It merged on 18 December 2024 and shipped in v15.46.1 and v14.78.4 the same day.

How do you patch it, in order of safety?

The recipes below run from least to most invasive. Prefer rolling the app forward to a fixed release; cherry-pick only when a customisation pins you to v15.46.0. The Docker tab is the same idea for a production bench inside frappe_docker.

# Roll the erpnext app forward to a tag that includes the fix
cd ~/frappe-bench

# 1. Verify what tag your site is on
bench version --format json | grep erpnext

# 2. Bump the branch/tag in apps.txt if you're pinned; otherwise:
bench switch-to-branch version-15 erpnext --upgrade   # or version-16 for the v16 line

# 3. Full update — pulls, migrates, builds, restarts
bench update --patch    # skips backup step; run 'bench backup' first, always

# --- Recommended pre-flight, do not skip ---
bench --site <your-site> backup --with-files
# --- After update, verify the reports actually run ---
bench --site <your-site> console <<'PY'
from erpnext.accounts.report.balance_sheet.balance_sheet import execute
execute({"company": "<your-company>",
         "from_date": "2026-04-01", "to_date": "2026-06-30",
         "periodicity": "Monthly", "accumulated_values": 1,
         "presentation_currency": "INR"})
PY

For the cherry-pick route on v15, use the commit from PR #44770, the version-15-hotfix backport of PR #44765 (v14: PR #44769); copy the SHA from the PR page.

Check the Company defaults before you smoke-test

Financial statements read GL Entries and the account tree. On a fresh install, check the Company master has default_currency set (it drives the presentation-currency default) and, if you post in foreign currency, that default_receivable_account and default_payable_account are filled. Blank values give mysteriously empty rows rather than an error, which people confuse with this regression after they patch and still see an empty Balance Sheet.

How do you verify the fix?

Who owns what on a bench with a real ops team?

The steps above assume one person owns bench maintenance, the month-end close and the patch decision. That works for a 20-user SME. Beyond that the responsibilities split, and the split matters:

Write this split down even for a five-person team: "who runs the patch" and "who decides it landed correctly" are different roles in every audit framework.

How do you harden against the next one?

v15.46 will not be the last change to break a statement report. ERPNext is under active development, and now and then a fix ships before every caller is tested; this one was caught and fixed within hours, but only because users reported it. The sensible posture is not "audit every commit" but "run each statement report once a night and shout if one raises". Forty lines of server script, no external dependency.

# Server Script → Type: Scheduler Event → Frequency: Daily (03:15 IST is fine)
# Runs each of the three financial statements against the current fiscal year and
# emails finance + ops if any of them raises. A future regression is then caught
# a day after it hits your bench, not on the 30th at 22:00.

import frappe
from frappe.utils import getdate, get_first_day, get_last_day
from erpnext.accounts.report.balance_sheet.balance_sheet import execute as bs_exec
from erpnext.accounts.report.profit_and_loss_statement.profit_and_loss_statement import execute as pl_exec
from erpnext.accounts.report.cash_flow.cash_flow import execute as cf_exec

COMPANY = frappe.db.get_single_value("Global Defaults", "default_company")
today = getdate()
frm = get_first_day(today).isoformat()
to  = get_last_day(today).isoformat()
filters = {
    "company": COMPANY,
    "from_date": frm,
    "to_date": to,
    "periodicity": "Monthly",
    "accumulated_values": 1,
    "presentation_currency": frappe.db.get_value("Company", COMPANY, "default_currency"),
}

failures = []
for label, fn in [("Balance Sheet", bs_exec),
                  ("Profit & Loss", pl_exec),
                  ("Cash Flow",     cf_exec)]:
    try:
        fn(filters.copy())
    except Exception as e:
        failures.append((label, type(e).__name__, str(e)[:400]))

if failures:
    rows = "".join(
        f"<tr><td>{r[0]}</td><td>{r[1]}</td><td><pre>{frappe.utils.escape_html(r[2])}</pre></td></tr>"
        for r in failures
    )
    frappe.sendmail(
        recipients=["finance@yourco.in", "ops-lead@yourco.in"],
        subject=f"[ERPNext] {len(failures)} financial statement(s) crashed on nightly check",
        message=(
            "<p>Nightly smoke-test of Balance Sheet / P&L / Cash Flow reports failed. "
            "Do not close month-end until this clears.</p>"
            f"<table border=1 cellpadding=6><tr><th>Report</th><th>Exception</th>"
            f"<th>Message</th></tr>{rows}</table>"
        ),
    )
else:
    # Optional: write a heartbeat so you can prove the check ran on audit day
    frappe.db.set_single_value("System Settings", "reports_last_verified_at", frappe.utils.now())

The script runs from Frappe's own scheduler, so it stays inside the bench and works even if outbound network access is firewalled. Run it as a user with typical finance permissions if you can; this bug only showed on the permissions path.

When should you hold a close?

If the guardrail sends the red email at 03:30 on the 29th and you close on the 30th, what is the right response? This draft is a starting point for your CFO and auditor to agree, not a rule:

Statement-Regression Response Policy (draft for auditor / CFO review): If Balance Sheet, Profit & Loss Statement or Cash Flow raises an exception on the nightly smoke test, put the current month-end on hold until Ops confirms a fix has landed and Finance has re-verified all three reports from the desk. The hold applies whether or not the failing report is on this close's checklist: a broken shared helper means every number derived from it (management dashboards, board pack, GST reconciliation drafts) must be re-verified. Escalation contact: on-call ERPNext ops lead. Target time to fix: < 24 hours for a regression with a known upstream patch; < 72 hours otherwise.

Two notes on writing it down rather than leaving it to judgement on the day:

• Auditors prefer a policy to improvisation. A written response, even a conservative one, is easier to defend at year-end than "we noticed and fixed it before close".
• The 24 and 72 hour targets are placeholders. A business closing on a 24-hour cycle needs tighter numbers; one with a five-day close window can loosen them. Anchor them to your existing incident-response targets.

Should you fix it now or backlog it?

Either way, the process fix, the nightly guardrail, is a single deploy and silent on green days. Install it.

What related issues might you hit?

• ERPNext bank reconciliation: the interactive fix guide: another accounting workflow with silent-drift failure modes.
• ERPNext Landed Cost & FX Gone Wrong: stock-valuation drift from stale exchange rates on the GRN.
• ERPNext BOM cost on Item master out of sync: how the BOM-to-Item cost link drifts on manufacturing benches.
• Tuning MariaDB for a real ERPNext workload: a report that crashes can hide a report that also times out.
• Real ERPNext bugs and their real fixes: triage patterns for other regressions from GitHub and the forum.

At a glance

FAQ: what do people ask most?

What should you do next?

Statement-breaking regressions happen: the code moves fast, and now and then a fix ships before every path is tested. The lesson from v15.46 is not that ERPNext is unstable; it was fixed within hours. It is that a self-hosted ERP with month-end obligations needs a nightly smoke test the way a production API needs a health check. Install the guardrail once, and the next regression becomes an ops-day problem instead of an audit-day one.