Start with Bizman POS through BriskRetail, and make payment reconciliation part of the checkout demonstration. Ask to see how the proposed setup distinguishes a sale, its payment methods, an unresolved payment and the later bank settlement. Your cashier should know whether the customer has paid; your bookkeeper should be able to explain where the money went.
For a shop that needs the sale to connect to stock, frame the wider requirement as Bizman Sales and Inventory. The objective is one explainable chain: goods sold, payment recorded, payment independently verified, stock moved and money reconciled. A receipt marked “transfer” does not establish that the merchant received funds.
This guide gives you a daily reconciliation template, a worked mixed-payment day and an exception log. It concerns payments for retail goods and services, not agent-banking withdrawals.
Commercial disclosure: BriskRetail supplies Bizman solutions and benefits commercially when you choose its services. Bizman POS is our primary recommendation for a scoped checkout evaluation. We have not performed the demonstrations below or verified a particular bank/acquirer integration. Requested capabilities must be demonstrated on your proposed configuration; no automatic payment verification is assumed.
Research checked: 23 October 2026. Provider descriptions come from official documentation, not hands-on tests. All trading figures and fees in the worked example are hypothetical, not current tariffs or customer results.
1. Separate the sale from the payment and settlement
A sale describes what the customer bought and the amount due. A payment attempt describes a request to move money. A confirmed provider result supplies payment evidence. A settlement describes the provider moving collected funds to the merchant's settlement account. These events can occur at different times.
Card authorisation is part of a provider's processing flow; it should not be confused with the later bank payout. Follow the agreed merchant acceptance process for the exact terminal or channel. Successful processing also does not mean that a transaction can never be disputed or reversed later.
Paystack's payment-verification documentation distinguishes pending, failed, reversed and successful transaction states. Its transaction dashboard identifies payments by reference and shows amount, status and channel. That is an example of independent payment evidence you can match to a sale; it does not establish a Bizman connection to Paystack. Sources: Paystack payment verification and transaction records.
Ask your Bizman POS presenter to show how staff can distinguish “payment method selected” from “payment confirmed”. Where verification is manual, the procedure should say who checks, which authorised provider screen or bank record they use, and what reference they record. Do not let a checkbox imply stronger evidence than you actually have.
2. Treat fake alerts as an evidence problem
A screenshot, a forwarded SMS or a customer's debit notification is not independent proof of credit to your business. It may be fabricated, refer to another beneficiary or describe an attempt that has not completed. Even a genuine debit message does not resolve what happened at the receiving end.
Use a merchant-controlled route: open the approved bank or provider application directly, or use its supported terminal verification process. Check the receiving account, amount, transaction reference, time and current status. Compare the actual transaction detail, not just a change in the displayed balance; other receipts may have arrived at the same time.
Moniepoint's official transfer-acceptance article explains a terminal-based process and discusses fabricated receipts or notifications. The article is older and its exact terminal steps require current confirmation; its sweeping anti-fraud language should not be read as a guarantee. Source: Moniepoint transfer-payment guide.
Before trading, agree what the cashier does when confirmation is unavailable. Hold the order and goods while investigating, offer a separately verified payment method, or use a genuinely authorised customer-credit process. Do not release goods merely because the queue is growing or the customer insists an alert is genuine.
If a second payment is made while the first is uncertain, record both attempts under the same order and retain both references. A later successful first attempt can produce an overpayment. Never refund a supposed duplicate based only on a screenshot; verify the actual receipts and use the approved refund process.
3. Record split payments without doubling the sale
Suppose a customer buys NGN 25,000 of goods and pays NGN 10,000 cash plus NGN 15,000 by transfer. There is one NGN 25,000 sale, with two payment allocations. Recording two full sales would overstate revenue and potentially deduct stock twice.
The allocations should sum to the amount due. If the transfer is still unverified, describe the remaining NGN 15,000 accurately. Do not represent the order as fully paid solely because a transfer amount has been typed into the till. If your configuration cannot hold this distinction, agree a controlled exception procedure before rollout.
Use a unique receipt/order identifier and keep the provider reference against the relevant allocation. A customer name and amount alone may not uniquely identify a payment. Two people can transfer the same amount within minutes, and a single customer can place more than one order.
For Bizman Sales and Inventory, ask the presenter to show the stock effect of a pending order, a completed sale, a cancellation and a refund with goods returned. Payment status and physical stock status are related but not identical. Goods held at the counter must not become both available for another customer and deducted as a completed sale without a clear rule.
4. Reconcile a synthetic trading day in three layers
The following example is hypothetical, with no discounts, returns, credit sales or taxes affecting the arithmetic. Amounts are NGN. Direct bank transfers go to the merchant's receiving account; card collections go through a separate provider pending settlement. One additional NGN 18,000 attempted order remains unpaid and its goods are held, so it is excluded from completed sales.
| Completed-sale group | Sale value | Cash allocation | Card allocation | Verified direct transfer |
|---|---|---|---|---|
| Cash-only sales | 120,000 | 120,000 | 0 | 0 |
| Card-only sales | 180,000 | 0 | 180,000 | 0 |
| Transfer-only sales | 150,000 | 0 | 0 | 150,000 |
| One split-payment sale | 25,000 | 10,000 | 0 | 15,000 |
| Total | 475,000 | 130,000 | 180,000 | 165,000 |
Layer one: sales to tenders. Completed sales of NGN 475,000 equal 130,000 cash + 180,000 card + 165,000 direct transfers. The unverified NGN 18,000 order stays on the exception list, not in the confirmed-transfer total. A different accounting treatment for an actual credit sale would need its own receivable record; that is not this example.
Layer two: cash to the drawer. Assume an opening float of NGN 20,000, documented shop expenses of NGN 5,000 paid from cash, and a documented NGN 100,000 safe drop. Expected drawer cash is 20,000 + 130,000 − 5,000 − 100,000 = NGN 45,000. A count of NGN 44,000 creates a −NGN 1,000 variance to investigate. The safe drop remains business cash in another location; it did not disappear from the business merely because it left the drawer.
Layer three: digital payments to their destinations. Match the NGN 165,000 direct transfers to credited transactions in the receiving account. Separately match the NGN 180,000 card total to successful provider transactions. Do not demand that the bank balance increase by the entire NGN 345,000 that same day: the card portion may still be awaiting payout.
Suppose, solely for illustration, the provider later settles all those card payments less NGN 2,700 fees, with no other deductions. Expected payout is 180,000 − 2,700 = NGN 177,300. Match that bank credit to the provider's payout record and the transactions included. NGN 2,700 is an invented teaching amount, not a quoted fee schedule.
The NGN 475,000 sales total, NGN 45,000 expected drawer balance and NGN 177,300 card payout are different measures. Making them equal by editing records would damage the reconciliation rather than finish it.
5. Explain settlement differences before treating them as shortages
Paystack describes collected payments entering a pending payout, with payout details showing fees and activities such as refunds or chargebacks. Its documentation supports reconciling the payout separately from the original transactions. Actual schedules and account/channel conditions must be checked for the merchant's arrangement. Source: Paystack payout documentation.
For each provider, start with the actual payout batch, not an assumption that it contains exactly one calendar day's sales. Check the cut-off, time zone, included transaction references, fees, refunds, dispute deductions and any other documented adjustments. Separate an unpaid balance awaiting settlement from an unexplained difference in a payout already received.
A refund is also a process, not just a button press. Paystack's refund guide distinguishes pending, processing, processed and failed states and explains that these affect transaction status. Keep the refund reference, amount and outcome linked to the original sale. Source: Paystack refund statuses.
A chargeback is a dispute-related payment issue; it is not automatically the same as a customer returning goods. Retain transaction and fulfilment evidence and follow the provider's case instructions and deadline. Do not invent a stock return when no goods came back, or issue another refund without checking whether funds have already been reversed or deducted.
6. Use a daily reconciliation template and an ageing log
For each shift or day, keep: branch, register, cashier, start/end time and time zone; completed sales; payment allocations; opening float; cash movements and count; provider totals; verified direct transfers; unresolved orders; payout batches; reviewer; and sign-off date. Keep transaction-level references behind every summary.
Add an exception log rather than forcing unresolved items into the “paid” column. The following entries are illustrative and the review intervals are an internal routine, not statutory or bank-resolution deadlines.
| Exception | Amount, NGN | Evidence/status | Owner and next action |
|---|---|---|---|
| Held order; transfer unverified | 18,000 | No receiving credit matched; goods held | Shift lead checks approved provider channel and contacts customer through normal process |
| Closing drawer short | 1,000 | Actual 44,000 versus expected 45,000 | Reviewer recounts and checks cash movements/tender coding |
| Card batch awaiting payout | 177,300 expected net | Synthetic batch not yet credited | Bookkeeper compares provider's applicable due date and payout status |
| Possible duplicate attempt | Record each actual amount | Two references; outcome unresolved | Manager verifies both before approving any refund |
For each item, record first-seen time, elapsed age, last action, support case reference, next review and resolution evidence. Review unresolved checkout payments during the shift, carry them explicitly into close, and assign follow-up at the next opening. Settlement exceptions follow the provider's applicable schedule, not an arbitrary promise of next-day credit.
Close an exception only when its outcome is documented. “Customer called” is an action, not a payment result. “Provider confirmed failed; held order cancelled; no goods released” is a clear resolution. If a correction changes sales, tender or stock records, retain the original reference and approval.
7. Escalate with a complete record
First investigate your own matching errors: wrong receiving account, wrong branch, amount mismatch, duplicate reference, date/time cut-off, refund or reversed transaction. Then contact the relevant bank or provider through an independently verified support channel. Keep the case number and evidence of the first report.
CBN's complaint guide directs customers to their financial institution first and explains escalation when the institution fails to handle the complaint under the applicable process. Its guidance also warns against including PINs or passwords in complaints. Use current official instructions for your complaint category; this guide does not prescribe a universal reversal deadline. Source: CBN complaint guide.
Provide the transaction date/time, amount, merchant/order reference, relevant provider reference, masked account information where appropriate, current status and the specific question you need answered. Do not send credentials, OTPs or full card security details, and avoid circulating customer records in a general staff chat.
If the customer reports a debit but your merchant record remains unsuccessful or unresolved, explain what has been checked without declaring the customer dishonest. Keep the order held under the agreed policy and help identify the appropriate support route. A failed or delayed transfer and a fabricated alert need different conclusions even when neither currently proves payment.
8. Choose the Bizman product area that matches the work
BriskRetail uses the Bizman names to describe the relevant product areas. Ask for the exact scope, configuration and any additional modules in writing; the names alone do not prove a particular integration or automation.
| Product-area name | When it fits this discussion | Demonstration to request |
|---|---|---|
| Bizman POS | Checkout, tender allocation, receipts and shift reconciliation | One split sale, a pending payment and an explained cash close |
| Bizman Sales and Inventory | Connecting completed sales, cancellations and returns to stock | Correct stock movement once, with separate payment evidence |
| Bizman Inventory | Checking whether goods were reserved, released, returned or transferred | Trace the physical-stock outcome of a disputed or cancelled order |
| Bizman Production Suite | A bakery, food producer or other business also needs production records | Explain how finished goods reach the selling stock before checkout; keep production costing separate from payment confirmation |
| Bizman | Discussing the overall platform and coordinated implementation | Agree responsibilities across the chosen product areas and payment providers |
For this article's main need, Bizman POS is the recommended starting point. Add the Bizman Sales and Inventory discussion when stock and sales reconciliation belong in the same implementation. A production business may also need Bizman Production Suite, but production functionality does not establish that a bank transfer succeeded.
Ask BriskRetail to confirm what each selected product area includes, which payment providers it supports and what your team will need to verify manually. Put those answers in the proposal before choosing your setup.
9. Test your proposed Bizman POS workflow before rollout
Use synthetic sales and provider test facilities where available. Do not send live customer money merely to demonstrate a screen. Ask BriskRetail to show the NGN 25,000 split sale, the NGN 18,000 held order, a payment timeout, a second attempt and the later reconciliation.
Test a refund with and without a physical return, a settlement net of documented fees and a disconnected till. Confirm whether bank/acquirer verification is integrated or manual for the proposed arrangement. If integrated, request evidence of supported channels and how failed notifications, retries and unmatched payments are handled. If manual, agree the authorised user, evidence and review process.
Record pass, fail or unverified for each requirement. Check that a repeated payment notification cannot create a second sale or second stock deduction, and that unresolved cases remain visible to a named reviewer. These are acceptance criteria, not claims that we have executed the tests on Bizman POS.
Give the cashier a short instruction sheet and the bookkeeper a reconciliation template. Review the first real trading days with the agreed support contact, measuring unresolved items and time to resolution rather than relying on a green dashboard alone.
Choose a Bizman POS setup whose records your team can explain. Explore Bizman or request a Bizman POS payment-reconciliation demonstration. Include your banks/providers, number of tills, split-payment needs and whether the scope also includes Bizman Sales and Inventory, Bizman Inventory or Bizman Production Suite.
