Clearing Account Cycle

Financial accounting mechanism used by Pride to track temporary cash flows between point-of-sale transactions and bank settlement. Critical to reconciliation integrity but currently broken due to staff coding errors and integration issues.

Concept

A clearing account is a temporary holding account that bridges a gap between when revenue is recognised (when the customer transaction occurs on the POS system) and when the money physically arrives at the bank. Clearing accounts should always trend toward zero over time—they are meant to be zeroed out when the associated cash arrives.

Core principle: Never record revenue directly against a bank deposit; always route it through an intermediate clearing account so you can capture fees, reconcile to the POS system, and maintain audit trail.

How Pride’s Clearing Accounts Should Work

For card payments (via Square):

1. Daily: Customer pays via card on Square POS
2. Daily: Amaka creates invoice debiting SQ-000000 (Square Balance clearing account) and crediting revenue (SQ-200000)
3. Next business day: Square deposits net amount to bank (gross revenue minus processing fees)
4. Daily: Amaka creates bank transfer from SQ-000000 to bank account AND bills processing fees to SQ-300000
5. Result: SQ-000000 trends toward $0; processing fees captured in P&L

For cash payments:

1. Daily: Staff enter cash on Square POS (e.g., $1,000 in cash takings)
2. Daily: Amaka creates invoice debiting SQ-600000 (Square Cash Clearing) and crediting revenue
3. Later (when staff deposit cash): Staff deposit $1,000 to bank
4. Staff/bookkeeper: Create bank receipt crediting SQ-600000, debiting bank account
5. Result: SQ-600000 trends toward $0; cash float properly recorded

For bank transfer payments:

1. Daily: Customer initiates bank transfer to Pride (e.g., $500)
2. Daily: Staff enter as “Other Tender” on Square POS
3. Daily: Amaka creates invoice debiting SQ-600002 (Other Payment Clearing) and crediting revenue
4. Later: Bank transfer arrives at bank
5. Bookkeeper: Create bank receipt crediting SQ-600002, debiting bank account
6. Result: SQ-600002 trends toward $0; revenue properly matched to bank arrival

Current Issues at Pride

Issue 1: SQ-000000 (Square Balance) — $4.67M unreconciled

• Amaka settlement transactions never reconciled against bank feed
• Does not represent missing money; represents internal reconciliation never performed
• Cannot trust bank statement reconciliation for this account
• Status: No correction proposed; requires manual investigation of 553+ settlement entries

Issue 2: SQ-600000 (Square Cash Clearing) — ($396,364.25) credit balance

• Should trend toward $0; currently shows massive credit (asset account with liability balance)
• Composition:
  • $343,663.85: Correct ATM float reclassification (deliberate multi-year adjustment; should remain)
  • ~$209,000: Zeller EFTPOS deposits miscoded to SQ-600000 (double-hit when Zeller settlement also deposits)
  • ~$20,700: Structural drift from FY24 (no year-end clearing journal; 3-week integration gap Aug 2024)
• Root cause: Staff ring Zeller card payments as “Cash” on Square POS (Zeller not integrated); Amaka clears to SQ-600000; Zeller settlement also coded to SQ-600000
• Correction: Reclassify Zeller deposits to dedicated Zeller clearing account; train staff on tender categorisation

Issue 3: SQ-600002 (Other Payment Clearing) — $27,968.32 debit balance

• Should trend toward $0; currently shows $27,968.32
• Balance growth pattern: $632 (FY23) → $2,677 (FY24) → $15,894 (FY25) → $27,968 (now)
• Root cause: Revenue double-counted. When bank transfers arrive, bookkeeper codes them directly to account 200 (revenue) instead of crediting SQ-600002
• Result: Revenue recognised twice—once via Amaka invoice (SQ-200000) and once via bank receipt (account 200)
• Correction: Post clearing journals per FY; establish process to credit SQ-600002 (not revenue) when bank transfer arrives

Accounting Best Practice

Clearing accounts are purely mechanical. They should:

• Trend toward zero over time (they are temporary, not permanent balances)
• Always match reconcilable events (e.g., SQ-600002 should balance to list of bank transfers pending)
• Never show unusual growth patterns
• Require reconciliation against source data (bank statements, POS system) regularly
• Be monitored in weekly cash reporting

Red flags:

• Clearing account with unusual balance direction (liability account with debit balance, asset with credit balance)
• Clearing account with growing balance over time
• Clearing account with long-standing items (items older than 1 week are suspect)

Related Pages

• Amaka — how Amaka syncs POS to clearing accounts
• Square POS — POS system generating the daily transaction flow
• Square Cash Clearing Issue — detail on Zeller EFTPOS miscoding
• Other Payment Clearing Issue — detail on bank transfer revenue double-count
• Bank Reconciliation — matching clearing accounts to bank statements