Reports
Reconcile Sales by Payment Method
The Types tab is the payment-method control total. Run it for the same branch and time window as the till close, then compare each method with the drawer, terminal, bank or wallet evidence.
- Menu path
- Reports -> Money -> Payment -> Types
- Verified from
- Posnic demo and current POS source reviewed on 2026-09-08
Technical source evidence
frontend/modules/paymentReport.html, frontend/static/script/js/modules/js/report_payment.js, api/src/controllers/sales.controller.js paymentSaleTypeReport, api/src/repositories/sale.repository.js getPaymentSaleTypeReport
Run the Payment Method Summary
- Open Reports -> Money -> Payment.
- Keep Types selected.
- Open Filter and choose the exact date range and branches used for close.
- Apply the filter.
- Read one row per payment method.
- Compare each row with its independent settlement evidence before approving the close.
Read Every Column
| Column | Meaning | Control use |
|---|---|---|
| Payment Type | Configured tender label stored on the sale or split-payment entry. | Match the label to the drawer, terminal, bank or wallet. |
| Total Amount | Recorded sale amount for the method; split tenders contribute their individual method amount. | Primary method control total. |
| Partially Collected | The sale partial balance apportioned by each split tender's share when multi-payment is present. | Flag bills that were not fully collected. |
| Outstanding Amount | Payment pending amount, apportioned across split methods when applicable. | Reconcile with Pending Payment Reports. |
| Refunds | Recorded returned amount, apportioned across split methods when applicable. | Compare with return transactions and provider refunds. |
| Total Transaction | Number of sale records contributing to the method; a split sale can increment more than one method. | Do not treat this as a customer or invoice count. |
How Split Payments Affect Totals
- For a sale with a populated multi_payment object, Posnic sums each positive method amount separately.
- Partial, outstanding and refund values are divided among those methods in proportion to each method's share.
- A split sale increments the transaction count once for every positive method entry.
- When no usable split-payment data exists, the full sale is assigned to payment_mode.
- Blank and N/A method rows are excluded from the displayed summary.
Close-Day Reconciliation
- Use the same date boundaries and branch everywhere.
- Compare cash with counted cash after opening float and authorized cash movements.
- Compare card, UPI, bank and wallet rows with provider batch totals.
- Open Sale Payment Transactions for the bills behind an unexpected method total.
- Open Return Sale Payment Transactions for refund evidence.
- Record unresolved differences before closing the register.
Troubleshooting
| Problem | Check | Action |
|---|---|---|
| Method is missing | Payment label, branch and date scope | Correct the scope and confirm the sale stored that method. |
| Split total looks unexpected | multi_payment values and each method's share | Trace the original bill and tender breakdown. |
| Cash differs from drawer | Opening float, cash in/out, refunds and wrong tender labels | Reconcile register activity before changing records. |
| Card differs from provider | Settlement cutoff, failed or duplicated payment | Match individual sale transactions to provider references. |
| Report is unavailable | Report Read permission and plan access | Correct role or subscription access. |