A cashier rings up sales, the day closes, and the POS Closing Entry reconciles the shift — except a handful of invoices aren't in it. They were created before anyone opened the POS shift for the day, so ERPNext left them out of the Closing entirely. They never became consolidated Sales Invoices, so the revenue, the tax and the payment never posted to your accounts. The cash is in the drawer; the sale is nowhere in the ledger. This guide shows how to find those orphaned invoices, the release that stops them being created, and how to bring the historical ones back into the books.
Setting POS up, rather than fixing it?
If you're still configuring retail POS — profiles, payment modes, tax — start with ERPNext POS for retail in India. This post assumes a running POS and a specific closing gap.
A missing error is more dangerous than a loud one: nobody investigates a sale that simply isn't there. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this is the POS fault that shows up as an unexplained gap between the till and the books.
What actually breaks
ERPNext's POS runs in shifts. A POS Opening Entry starts the shift and records the opening float; cashiers create POS Invoices through it; a POS Closing Entry ends the shift, reconciles the payments, and consolidates the shift's invoices into Sales Invoices that post the accounting. The Closing Entry finds the invoices to consolidate by looking in the window between the Opening and Closing times.
The defect fixed by PR #46907 is that ERPNext let a POS Invoice be created before a POS Opening Entry existed for that profile. Such an invoice has a timestamp earlier than the Opening, so it falls outside the consolidation window, and the Closing Entry never sweeps it in. The sale is captured as a POS Invoice — the customer paid, the cash is real — but it never becomes a consolidated Sales Invoice, so no revenue, tax or payment entry posts. It simply sits outside every closing, indefinitely.
The v15.56.0 fix adds a validation: a POS Invoice cannot be created unless a POS Opening Entry exists for the POS Profile. That prevents the orphan at source. It does nothing for invoices already stranded — those you have to find and reconcile.
Toggle whether the shift was opened first, whether an invoice landed at the close, and your version to see whether the shift will consolidate fully.
On a release below v15.56.0, POS Invoices created before a POS Opening Entry exists are not swept into the POS Closing Entry. They stay unconsolidated — real sales that never reach a Sales Invoice or the closing reconciliation. Upgrade so the invoice cannot be created before the shift is opened.
Models the behaviour fixed by frappe/erpnext PR #46907 / #46910 (merged, ERPNext v15.56.0, 8 Apr 2025). Confirm your release before relying on the enforcement.
The cash reconciles even when the ledger doesn't
This fault is quiet precisely because the physical cash still balances at the till — the cashier took real money for a real sale. The gap only appears when someone compares total sales revenue in the accounts against the till takings, or when a GST return comes up short against the payment gateway. By then it is weeks of orphans, not one. Run the report before it gets there.
Five POS closing faults, and which is yours
POS closing has several distinct issues that all read as "a sale is missing from the close". They have different causes and fixes.
Select the POS closing symptom you are seeing to identify the underlying cause, the tracking issue, and the fix path.
Pick the POS closing symptom you are seeing.
The before-opening orphan is the one v15.56.0 fixes. Separate from it, an invoice timestamped at the exact Closing moment can still fall outside the window (#41036), Sales Invoice creation can be skipped for some invoices during the close, and in multi-company setups the change-amount account can be pulled from the wrong company (#40866). They share a symptom — a sale that should be in the accounts isn't — and each needs its own check. The common defence is the same reconciliation: after every close, the count of POS Invoices in the shift must equal the consolidated Sales Invoices.
Fix it
Copy-paste the orphan report, the bench upgrade to v15.56.0, the reconciliation steps for historical orphans, and the shift discipline that prevents recurrence.
Locate POS Invoices that never made it into a Closing Entry. These are real sales missing from your consolidated accounts.
Report Builder → POS Invoice
Filters:
• Status = Paid / Submitted
• Consolidated = No (field: "consolidated_invoice"
is empty)
Columns:
posting_date, posting_time, pos_profile, grand_total,
owner
Any row here is a POS Invoice that was NOT rolled into a
POS Closing Entry. Cross-check its posting_time against
the POS Opening Entry for that profile and date:
• Invoice time BEFORE the Opening Entry → the
before-opening orphan (fixed in v15.56.0)
• Invoice time == the Closing time → the
at-close orphan
Sum grand_total of the orphans — that is the sales value
currently missing from your consolidated Sales Invoices.Find the orphans and price them
Build a Report Builder view on POS Invoice filtered to Consolidated = No. Every row is a POS Invoice that never made it into a Closing. Sum the grand totals — that is the sales value currently missing from your consolidated accounts, and it is the number that makes this a priority rather than a curiosity.
Classify each one
Compare each orphan's posting time against the POS Opening and Closing times for its profile and date. Invoices timed before the Opening are the before-opening orphans this fix addresses; invoices timed at the Close are the separate window orphan. Knowing which is which tells you whether the upgrade alone prevents recurrence.
Upgrade to v15.56.0 or later
Back up with files, update the erpnext app on the version-15 branch, and confirm you are on 15.56.0 or later. On staging, try to create a POS Invoice with no Opening Entry for that profile — it should now be blocked. This stops new orphans; it does not touch the ones you just found.
Reconcile the historical orphans
For each orphan, create the missing consolidated Sales Invoice so the revenue, tax and payment post, dated in the correct open period with a narration referencing the original POS Invoice. If the period is closed, post in the current open period referencing the original date rather than reopening a closed period without accounts' approval — the same discipline that governs the asset-scrap closed-period case.
Reconcile the tender and re-check
Match the POS payment already banked — cash or card — against the entry you posted, so the money that was physically taken lines up with the accounting. Then re-run the orphan report and confirm the count and value have dropped to zero. This ties into your routine bank reconciliation, where the till takings finally meet the ledger.
When the cashier, the manager and the accountant are three people
The cashier who created the pre-opening invoice did nothing obviously wrong — they rang up a sale before remembering to open the shift, and the system let them. The floor manager who runs the close sees a Closing Entry that looks complete. The accountant who eventually spots the shortfall is a month downstream and cannot tell which shift, which till, or which cashier it came from.
No single person in that chain sees the orphan, which is why it survives. The control that works is a reconciliation nobody has to remember: after each close, the POS Invoice count for the shift must equal the consolidated Sales Invoices, and any mismatch is escalated the same day. Pair it with the shift-order rule — open the shift before the first sale — which on v15.56.0 the system now enforces, but which floor staff should understand as a rule rather than a system quirk, so they follow it on any till still awaiting the upgrade.
Draft policy for your retail and finance leads to ratify. A POS shift is opened (POS Opening Entry) before the first sale of the day, on every till. After each Closing Entry, the number of POS Invoices in the shift is reconciled against the consolidated Sales Invoices, and any difference is escalated to finance the same day. Orphaned POS Invoices are reconciled into the current open period, referencing the original date, with the banked tender matched to the posted entry; closed periods are not reopened for a historical orphan without the accounts owner's approval. Tills below ERPNext v15.56.0 are prioritised for upgrade because the shift-order rule is unenforced there. Confirm the period treatment with your auditor before this enters an SOP.
Upgrade now, or reconcile first
FAQ
+Why are some POS invoices missing from the closing entry in ERPNext?
Because they were created before a POS Opening Entry existed for that shift. The Closing Entry only consolidates invoices in the window between the Opening and Closing times, so a pre-opening invoice falls outside it and is never swept in. It is fixed in v15.56.0 by PR #46907.
+Which ERPNext version fixes the POS opening entry bug?
+How do I find POS invoices that were never consolidated?
Use Report Builder on POS Invoice filtered to Consolidated = No. Every row is an invoice that never entered a POS Closing Entry. Compare each one's posting time to the Opening and Closing times for its profile and date to see whether it predates the Opening or lands at the Close.
+Does upgrading fix the sales that are already missing?
No. The v15.56.0 fix prevents new orphans by blocking invoice creation before the Opening Entry, but it does not reconcile invoices already stranded. You must find those with the orphan report and create the missing consolidated Sales Invoices yourself, in the correct period.
+What happens to my accounts if I leave the orphans?
Real sales stay outside your revenue, tax and payment postings, so your accounts understate income and GST while the cash sits reconciled at the till. It usually surfaces as an unexplained gap between till takings and booked revenue, or a GST return short against the payment gateway — and the longer it runs, the harder it is to attribute each orphan to its shift.
+Can an invoice still be missed after upgrading?
Yes, a different and narrower case: an invoice timestamped at the exact Closing moment can fall outside the Opening–Closing window (#41036). Leave a moment between the last sale and closing the shift, and keep the post-close reconciliation of invoice counts as a standing control.
Related issues you may also hit
- An invoice at the exact close time, or Sales Invoice creation skipped during close (#41036, PR #44772).
- Wrong company's account in a multi-company POS close (#40866).
- ERPNext asset scrap triggers depreciation on a closed period — the same closed-period discipline for corrections.
- ERPNext GST return filing — where missing POS revenue shows up as a shortfall.
Closing
The fault is fixed in a point release, but the money it stranded doesn't return on its own. Run the orphan report, put a number on what's outside your accounts, upgrade the tills so the shift-order rule is enforced, and reconcile the historical orphans with your accountant. Then make the post-close invoice-count reconciliation routine — it is the control that would have caught this on day one.
Till takings and booked revenue don't agree and no one knows why?
We find every orphaned POS Invoice, price the gap, upgrade your tills to enforce shift order, and reconcile the stranded sales back into your accounts.