Balance Sheet Net Income Does Not Match the Profit and Loss

When the net income figure on your balance sheet disagrees with the one on your profit and loss, the ledger is telling you something. Most of the time it is a reporting mismatch rather than a posting error. Occasionally it is a symptom of data damage. The skill is telling the two apart quickly, before anyone starts changing transactions to force a tie-out.

Why the two reports can legitimately differ

The balance sheet is a point-in-time statement. The profit and loss covers a period. The net income line on the balance sheet is derived from the current fiscal year to date, so the two figures only agree when the P&L is run over exactly that same span, on the same basis, with the same filters.

A mismatch is therefore expected whenever the reports are not truly comparable. Check these before anything else:

• Date range. Run the P&L from the first day of the fiscal year to the balance sheet date, not "this month" or a rolling twelve months.
• Accounting basis. Cash and accrual produce different net income. Set both reports to the same basis.
• Filters. A class, location or customer filter applied to one report and not the other will break the tie. Clear filters on both and re-run.
• Fiscal year start. If the fiscal year preference is set to the wrong month, the balance sheet derives net income over the wrong window. Verify it in the company settings, under report information.

The quick proof

Set the balance sheet date to the last day of the fiscal year, set the P&L to the full fiscal year, put both on accrual, and display the P&L columns by year. If the figures now match, the ledger is fine and the earlier mismatch was presentation. Document the settings you used in the working paper so next month's close starts from a known-good configuration.

When it stops being a reporting issue

If the reports still disagree on identical dates, basis and filters, the cause is usually one of two things. Either income or expense transactions have been posted with dates outside the visible range in a way that skews the equity roll-forward, or the file itself is damaged.

A plain posting mistake tends to be findable. You can trace it: a journal dated in the wrong year, a transaction mapped to an equity account instead of an income account, an unclosed prior period. These are bookkeeping problems and you fix them in the ledger, with an audit trail.

Data damage behaves differently. Look for these signs:

• The discrepancy survives every setting change and even a file rebuild.
• The balance sheet is out of balance, with assets minus liabilities not equal to equity.
• Transaction detail reports show totals that do not foot to the summary.
• Reports render differently after a verify or rebuild, or the file throws errors on verification.

What to preserve before anyone touches the file

If you suspect damage, stop editing. Take a verified backup, or a portable copy, before any rebuild is attempted. Note the exact report settings, the discrepancy amount and the date it first appeared. That evidence helps a specialist distinguish corruption from a configuration fault, and it protects you if the rebuild itself changes results.

Where the handoff point sits

Reconciling the two figures, checking settings and correcting misdated or miscoded postings is bookkeeping, and it belongs with you. Rebuilding a damaged file, repairing list damage and recovering a ledger that will not verify is a different discipline. If the discrepancy survives a clean settings comparison and the file fails verification, it has left your lane. At that point, hand over the backup and the notes, and see our QuickBooks error code repair service rather than attempting the repair yourself.

A mismatch you can explain is a presentation lesson. A mismatch you cannot explain, on identical settings, is a warning. Knowing which one you are looking at is half the close.