1. Fiscal Overview & Double-Entry Accounting Core Principles
In retail and commercial trading across emerging and multi-tier markets, informal customer store credit (traditionally termed Khata) drives significant trade volume and customer retention. However, tracking credit balances via physical paper notebooks or disconnected single-entry spreadsheets introduces severe financial vulnerabilities:
- Unreconciled Cash Leakage: Cashiers receiving informal cash settlements frequently fail to record entries in central accounts, leading to disputed customer balances.
- Hidden Receivables Aging: Store owners lack visibility into aged debt, resulting in stale accounts that silently erode working capital.
- Double-Entry Decoupling: Store credit transactions fail to integrate into the central Chart of Accounts, rendering end-of-month balance sheets and tax disclosures inaccurate.
- Disputed Customer Balances: Lack of standardized, time-stamped thermal settlement receipts generates friction between merchants and patrons during periodic account reconciliation.
Orbit Commerce resolves these structural liabilities through an immutable, double-entry credit ledger subsystem. Every credit issuance and counter settlement commits simultaneously to customer sub-ledgers and the general ledger persistence kernel, guaranteeing mathematical balance and audit non-repudiation.
Fundamental Customer Khata Double-Entry Invariants
Strict Invariants
Total debits must strictly equal total credits at transactional commit. Every charge and settlement must satisfy zero penny variance.
Customer ledger entries are strictly append-only. Historical lines cannot be modified or deleted; corrections mandate reversing contra-vouchers.
Every ledger transaction captures and persists the running customer balance in property balanceAfter for zero-latency balance sheet inquiries.
Counter settlements cannot exceed the customer outstanding debt balance, preventing unearned customer liability corruptions in receivables.
2. Chart of Accounts (COA) Architectural Mapping
The Khata credit engine interfaces with the enterprise general ledger through dedicated balance sheet and operating expense accounts:
| Account Code | Account Classification | Normal Balance | Transaction Trigger | Balance Sheet / P&L Reporting Impact |
|---|---|---|---|---|
1010 Cash on Hand | Current Asset | Debit (Dr) | Cash payment received at counter for debt settlement. | Increases liquid cash assets on Balance Sheet. |
1020 Bank Clearing (Card) | Current Asset | Debit (Dr) | Debit/credit card payment processed via POS terminal. | Increases bank clearing assets on Balance Sheet. |
1030 Mobile Wallet Clearing | Current Asset | Debit (Dr) | Mobile wallet payment (JazzCash / EasyPaisa / Online). | Increases digital clearing assets on Balance Sheet. |
1050 AR - Customer Khata | Current Asset | Debit (Dr) | Credit sale issued (Dr) or settlement received (Cr). | Represents total gross trade receivables from customers. |
1059 Allowance for Doubtful AR | Contra-Asset | Credit (Cr) | Periodic impairment provision for aged debt (> 90d). | Offsets gross receivables on the Balance Sheet. |
2010 Sales Tax Payable | Current Liability | Credit (Cr) | Tax liability recognized upon initial invoice issuance. | Increases tax obligations owed to fiscal authority. |
4010 Retail Merchandise Revenue | Operating Revenue | Credit (Cr) | Merchandise delivered to customer on credit terms. | Increases net sales revenue on Income Statement. |
5040 Bad Debt Expense | Operating Expense | Debit (Dr) | Uncollectible debt written off by management directive. | Decreases net operating income on Income Statement. |
3. The 5-Column Double-Entry Customer Ledger Interface
The core operational artifact for customer credit administration is the 5-column ledger broadsheet, displaying chronological debits (charges), credits (settlements), and atomic running balances:
Malik Tariq Mehmood
CUST-00429
CREDIT ACTIVE
Phone: +92 300 5551234 · Account Opened: 2026-03-15 · Terms: Net 30
| Posting Date (UTC) | Document Reference & Notes | Debit (Charge) | Credit (Settlement) | Running Balance |
|---|---|---|---|---|
| 2026-10-06 14:22 | Invoice #INV-2026-09812 Retail grocery checkout · 8 line items | PKR 3,250.00 | -- | PKR 14,250.00 |
| 2026-10-04 11:05 | SETTLEMENT Cash Settlement at Till 2 (Ref #SET-0081) | -- | PKR 5,000.00 | PKR 11,000.00 |
| 2026-09-28 19:40 | Invoice #INV-2026-09241 Whole bean coffee & olive oil supplies | PKR 6,250.00 | -- | PKR 16,000.00 |
| 2026-09-15 16:10 | Invoice #INV-2026-08872 Initial monthly provisioning order | PKR 9,750.00 | -- | PKR 9,750.00 |
4. Visual Double-Entry Transaction Flow & Journal Vouchers
Every interaction with the customer credit account dispatches balanced journal vouchers to the central general ledger. The architectural diagram below traces the end-to-end capital flow from POS checkout credit charging through Accounts Receivable sub-ledgers, multi-rail counter settlements, and general ledger journal voucher reconciliation:
Khata Credit Issuance, AR Ledger & Settlement Flow
Double-Entry Invariant
Production Journal Voucher 1: Issuing Goods on Credit (Sale)
- Voucher ID: JV-2026-10-009842
- Description: Recognition of credit sale for customer CUST-00429 (Invoice #INV-2026-09812)
- Accounting Invariant: Strict matching principle recognizing revenue upon physical transfer of goods.
| Account Number & Title | Classification | Debit (Dr) | Credit (Cr) |
|---|---|---|---|
| 1050 AR - Customer Khata | Current Asset | PKR 3,250.00 | -- |
| 4010 Retail Merchandise Revenue | Operating Revenue | -- | PKR 2,801.72 |
| 2010 Sales Tax Payable (16% GST) | Current Liability | -- | PKR 448.28 |
| Balanced Total Verification | Zero Discrepancy | PKR 3,250.00 | PKR 3,250.00 |
Production Journal Voucher 2: Cashier Counter Settlement (Cash)
- Voucher ID: JV-2026-10-009914
- Description: Customer partial debt settlement at cash register (Receipt #SET-0081)
| Account Number & Title | Classification | Debit (Dr) | Credit (Cr) |
|---|---|---|---|
| 1010 Cash on Hand | Current Asset | PKR 5,000.00 | -- |
| 1050 AR - Customer Khata | Current Asset | -- | PKR 5,000.00 |
| Balanced Total Verification | Zero Discrepancy | PKR 5,000.00 | PKR 5,000.00 |
Production Journal Voucher 3: Digital Wallet Settlement (JazzCash / EasyPaisa)
- Voucher ID: JV-2026-10-010042
- Description: Customer balance clearance via digital wallet transfer with gateway transaction reference
| Account Number & Title | Classification | Debit (Dr) | Credit (Cr) |
|---|---|---|---|
| 1030 Mobile Wallet Clearing | Current Asset | PKR 4,750.00 | -- |
| 1050 AR - Customer Khata | Current Asset | -- | PKR 4,750.00 |
| Balanced Total Verification | Zero Discrepancy | PKR 4,750.00 | PKR 4,750.00 |
5. Derived FIFO Aging Buckets & Bad Debt Allowance Rules
To assess credit exposure without requiring slow batch cron recalculations, Orbit Commerce derives debt aging dynamically using an in-memory First-In, First-Out (FIFO) reconciliation kernel.
FIFO Debt Reconciliation & Aging Allocation Pipeline
First-In First-Out Allocation
Figure 3.1: Deterministic FIFO aging pipeline applying partial settlements against the oldest open debit records first and partitioning residual balances into aging buckets.
5.1 Aging Bucket Criteria
Aging buckets are defined relative to the current business date:
- Current (0 to 30 Days): Fresh charges within standard commercial credit terms. Zero provisioning required.
- Tier 1 Overdue (31 to 60 Days): Moderate aging. Triggers automated SMS payment reminders to the customer.
- Tier 2 Overdue (61 to 90 Days): Elevated default risk. Point-of-sale terminals enforce a soft warning when cashiers attempt new credit charges.
- Impaired / Default (90+ Days): Critical default exposure. The system enforces an automated credit freeze, blocking new charges until the account is settled.
5.2 Allowance for Doubtful Accounts (IFRS 9 Expected Credit Loss)
At month-end, the accounting director calculates the bad debt reserve by applying historical loss rates against the aging matrix:
Allowance = (Current * 0.5%) + (Tier1 * 2.0%) + (Tier2 * 10.0%) + (Impaired * 50.0%)
The resulting sum is booked as an adjusting general ledger journal entry:
- Debit (Dr): Account 5040 - Bad Debt Expense.
- Credit (Cr): Account 1059 - Allowance for Doubtful Khata Accounts.
5.3 Multi-Branch Customer Debt Consolidation & Audit Confirmation Protocols
For retail enterprises operating across multiple branch stores, warehouse dispensaries, and wholesale depots, customer credit balances must reconcile across geographic borders without creating localized double-spending risks:
- Centralized Customer Balance Authority: While registers cache customer profiles for rapid local lookup, the active debt balance is governed by the relational persistence kernel. A customer purchasing goods on credit at Branch A immediately consumes their unified credit limit across Branch B and Branch C within sub-second synchronization windows.
- Periodic Balance Confirmation Statements: At the close of each fiscal month, the financial controller generates formal Customer Balance Confirmation letters. The system exports an itemized breakdown of open charges, settlements, and aging classifications, allowing commercial patrons to cross-examine transactions against their internal purchase orders.
- Dispute Quarantine Workflows: If a customer disputes a historical charge during audit confirmation, the financial controller can flag the specific invoice transaction as DISPUTED. The dispute flag isolates the charge from automated credit lockout rules while an administrative investigation reviews register camera logs and signed physical delivery slips.
6. Multi-Rail Counter Tender Settlements & 80mm Thermal Voucher Printing
When a customer arrives at the retail counter to make a payment against their Khata debt, the cashier initiates a settlement transaction:
- Customer Selection: Locate the customer via phone number, national ID, or account code using the customer picker.
- Amount Entry: Enter the payment amount. The system validates that
amount <= currentBalance. - Payment Rail Selection:
- Cash: Cashier counts currency notes and records tender amount.
- Card: Cashier swipes card on integrated terminal and verifies transaction approval.
- Mobile Wallet: Cashier selects JazzCash or EasyPaisa, verifying the electronic transaction reference ID as outlined in split-tender cashiering and offline resilience.
- Atomic Submission: The POS submits
POST /v1/commerce/khata/settle. - 80mm Thermal Voucher Printing: The system immediately dispatches an ESC/POS print payload to the counter receipt printer.
6.1 Thermal Receipt Wire Format (ESC/POS Sample)
FRONTORBIT COMMERCE RETAIL
CUSTOMER KHATA SETTLEMENT SLIP
Customer Signature: ____________________________
Thank you for your timely settlement.
Please retain this slip for your account records.
7. Financial Failure Modes, Ledger Discrepancies & Recovery Matrix
The following operational matrix details frontline triage procedures for customer credit anomalies and ledger variances:
| Failure | Root Cause | Recovery SOP |
|---|---|---|
| Credit Charge Blocked: Limit Exceeded | Outstanding debt plus current checkout total exceeds the customer's configured creditLimit. | Inspect customer credit profile. If authorized by store manager, update credit limit in customer settings or execute split tender: charge up to limit on Khata, and settle remaining sum with Cash. |
| Settlement Rejected: Amount Exceeds Balance | Cashier entered an amount greater than the active outstanding debt balance. | Verify the exact balance on the broadsheet. Re-enter the settlement for an amount less than or equal to current balance. If customer desires to store advance credit, issue a customer deposit credit memo. |
| Customer Disputed Historical Balance | Cashier previously recorded cash payment under general sales rather than tagging customer Khata ID. | Print 5-column ledger statement. Cross-reference disputed date against end-of-day register shift cash drop reports. If cash overage is confirmed, issue a corrective manual journal adjustment. |
| Sub-Ledger vs General Ledger Divergence | Direct manual journal entry posted to Account 1050 without referencing a specific customerId. | Run the sub-ledger reconciliation script. Restrict manual journal postings to Account 1050 to system-generated vouchers. Post corrective balancing entries to restore parity. |
| Thermal Printer Paper Jam During Voucher Print | 80mm printer paper roll exhausted during settlement print sequence. | Reload thermal paper roll. Navigate to customer ledger view, locate the settlement row, and select Re-Print Settlement Voucher to emit a duplicate receipt stamped with duplicate indicator. |
8. Cross-Functional Platform Architecture Dependencies
The customer credit subsystem interfaces directly with complementary modules across the platform:
- Cashiering Operations: Multi-tender checkouts incorporating credit portions are governed by split-tender cashiering and offline resilience.
- Hospitality Khata Settlement: On-counter hospitality settlements mirror the workflow documented in quick khata on counter debt settlement.
- Fiscal Tax Compliance: Invoices settled on credit terms generate tax documents conforming to zatca phase 2 e-invoicing and cryptographic clearance.
- Physical Stock Reconciliation: Cost of goods sold for credit sales ties directly into physical stock take broadsheet and fefo reconciliation.
9. Fiscal Compliance, Tax Auditing & High-Value Accounting FAQs
When is sales tax recognized on a credit sale versus a cash sale?
Under both accrual GAAP and regional tax authority regulations (such as FBR and ZATCA), sales tax liability is recognized at the moment of invoice issuance and delivery of goods, regardless of when cash is collected from the customer.
How does the system handle credit sales when the register is operating in offline mode?
Offline registers can record credit charges against cached customer profiles only if the customer's cached balance plus the new sale does not exceed their offline credit authorization ceiling. Replay synchronization posts the charge upon WAN restoration.
Can an operator delete or backdate an incorrect settlement entry?
No. To preserve regulatory non-repudiation and prevent embezzlement, customer ledger entries are strictly immutable. Correcting an erroneous settlement requires issuing an authorized reversal credit memo signed by a store controller.
What is the maximum number of ledger rows retained for a customer?
The relational persistence kernel retains an infinite, unbroken audit trail of all historical charges and settlements. The operational UI broadsheet queries records with configurable pagination (default 50 records per page), computing balances across the complete historical timeline.