Accounting Troubleshooting

This standard is the accounting runbook for All About Pawz, LLC: symptom, where to look, and recovery, for the money problems that recur on the Platform. The Accounting Operator works the steps in order: each step eliminates a class of cause before the next is considered: and the Accounting Manager owns any problem that survives the runbook. One rule governs all of it: the books are never corrected by editing a posted entry. Corrections are reversing entries linked to the original, under Books. A troubleshooting session that ends with an edited posted entry has created a second problem.

"The money arrived but the books do not show it"

The most common money problem on the Platform, with four distinct causes. Eliminate them in order

1. The event never posts. Subscription renewals write the payment records and mirror the register: no books entry, by the present arrangement, under Sales. Manual payments recorded through the finance action create the register record: no books entry, under Payments (Accounting Payments). Refunds issued from the processor's own console write a negative payment record: no books entry and no refund record, under Refunds and Disputes. Where the missing money is one of these three, the recovery is the same: create the missing record and post the journal entry by hand. The month-end close includes standing steps for all three until the postings are connected.
2. The posting failed without stopping the event. The payment notice's books posting and every finance action's posting are best-effort: an error is recorded and the operational event completes anyway. Search the journal by the event's source reference: payment identifier, order identifier, refund number. Where the entry is absent, the posting failed: post it manually with the same lines the automated posting would have used, as documented in Sales through Register. Then check the error record for why it failed: an unknown account code from a deactivated account, a missing accounting entity for a new tenant, or an unbalanced entry from a discount line added to one side are the usual causes, and the cause determines whether other postings are failing too.
3. The entry is unposted. Automated postings go directly to posted; manual entries begin unposted, and an unposted entry is invisible to every report under Reports. Where the journal holds the entry and the Profit & Loss does not, check its state and post it.
4. Wrong period. Reports select on entry date. A sale dated in March but posted in April is in March's Profit & Loss and absent from April's. Confirm the entry date before concluding the entry is missing.

"The books and the operational records disagree"

1. Pick a direction and quantify it. Where the payment register shows more revenue than the books: list the register's succeeded payments for the period, list the books' revenue postings, and match by source reference. The unmatched items are the never-posted and failed-posting events from the gap list above.
2. Where the books show more than the register: look for duplicate journal entries. The books posting carries no duplicate check of its own, so a repeated payment notice that re-ran the sale handling posts twice. Search the journal by the payment's source identifier and reverse the extra entry.
3. For receivables: the invoices' outstanding total shall agree with the receivables control account. Where it does not, the usual causes are a mark-paid whose books posting failed: the invoice reads paid and the books never relieved the receivable: or a voided paid invoice whose reversal entry failed. Both leave the detail and the books differing by exactly the invoice's amount; match invoice by invoice, under Invoices.

"The Trial Balance does not agree"

The posting function rejects unbalanced entries, so a persistent imbalance is serious.

1. Re-run the report first: a report executed while a posting was half-completed can catch a partly written set of entries.
2. Where the imbalance persists, the General Ledger ordered by entry shows the offending entry: the one whose debits do not equal its credits. The causes are a manual entry that bypassed the posting function, or an earlier correction that edited posted lines directly.
3. Recovery is a balancing entry that returns the books to balance, with a memo explaining the correction and referencing the offending entry. The lines are never edited to repair it; an edit is what caused it.

"The bank reconciliation will not clear"

Work the difference in the order given in Banking: outstanding items (timing, legitimate), bank-only items (fees and interest: post them), book-only items (entries with no real-world counterpart: reverse them), and wrong-account postings. The known wrong-account hazard: the shop sale posts to checking, but the refund action credits cash. A card sale refunded through the administrative action leaves the books' checking balance wrong by the refund amount while the bank is right; move the refund entry to checking by correcting entry.

Round-number differences are whole missing transactions: search for an unposted refund or fee before hunting for keying errors. Small differences are usually bank fees the books missed. A one-cent difference is still unreconciled: the reconciliation is recorded complete only at exactly zero, and that is the standard.

"A payment is stuck in pending"

Only succeeded means money moved.

1. Check the processor first. Where the processor shows the payment captured, the Platform's record-keeping missed it: record it manually and post the books entry by hand, noting that manual records post no journal entry.
2. Where the processor shows it uncaptured, it was never money: follow up with the customer or let the authorization expire.
3. Pending is not a state to monitor; it is a state to resolve. See Payments (Accounting Payments).

"The deposits liability keeps growing"

Deposits are being collected but never applied, released, or forfeited, under Deposits.

1. Run the stale-deposit check: every held deposit past its expected service date is either work performed but never invoiced: invoice it and apply the deposit: or work never performed: release or refund it.
2. Assign the queue to a named operator. A liability that only grows is a queue nobody is working.

"A Seller's payout never arrived"

1. "Paid" means the processor accepted the instruction; the money then travels on the processor's timeline. Check the payout's processor identifier in the processor's console before treating the Platform as having failed.
2. Where the payout failed, the destination and failure reason are on the record: wrong bank details and closed accounts are the usual causes. Correct the cause and re-issue; never edit the failed record.
3. Where the Seller's balance grows with no payouts at all, that is a capability freeze during a dispute investigation: an enforcement hold, released only by the trust and safety decision, not an operator action. See Payments (Accounting Payments) and Refunds and Disputes.

"The payment notice is failing"

Notice signature failures mean the processor's events never reach the Platform: no operational updates, no books postings, nothing. The symptom in the accounting records is silence: payments the processor shows as captured with no Platform record at all.

1. Check the notice endpoint's recent deliveries in the processor's console. Failed signatures point to a signing-secret mismatch: the secret was rotated without updating the Platform's configuration. Repeated timeouts point to the handler taking too long.
2. Until delivery is restored, every event in the gap is reconciled by hand: take the processor's event list for the outage window and match each event against the Platform's records.

"Tax payable does not match what was collected"

The reconciliation has three parts: the tax service's computed totals, the Platform's sales-tax-payable balance, and the filed return, under Taxes.

1. Where the service computed tax but the payable is short: the tax line posts only where tax was collected, and a sale whose tax computation failed at checkout: the retry-without-tax fallback: carries no tax. Those sales are the gap.
2. Where the payable exceeds the service's totals: a manual entry or a register sale posted tax the automatic calculation did not. Verify the manual entries before assuming the automatic side is wrong.

The recovery order

Where the cause is found, correct it at the right level, in this order

1. The source: a deactivated account, a missing configuration, a failing notice delivery. Correct the source, or every future event fails the same way.
2. The missing record: create the refund record, the payment record, or the books entry that should exist, posting with the same lines the automated posting would have used.
3. The correction: a reversing entry linked to the original for anything posted wrong. Never an edit.

After every incident, the operator records what would have caught it earlier: a weekly processor-refund-to-books match, a stale-deposit review, a weekly Trial Balance check: and the Accounting Manager adds that check to the standing routine where it belongs. The runbook grows with every failure it survives.

Controls

• No posted entry is edited, no period is reopened, and no reconciliation is forced under any circumstance in this runbook; corrections follow Books and Banking.
• Separation of duties holds during recovery: the person who posts a recovery entry does not reconcile the account it lands in.
• Refund recoveries are made under the Returns and Refunds Policy and disputes under the Chargeback Policy; a recovery never creates a second refund to repair a missing record.
• Banking and processor credentials encountered during diagnosis are never recorded in an incident note, a memo, or any other document.

Records created and where they are kept

Recovery entries with their explanatory memos, incident notes, the processor-match lists, and the updated close checklist are kept with the accounting records for the period concerned and retained under the Regulatory Record Retention Policy.

Escalation

A problem that survives this runbook, a Trial Balance that will not agree, or any indication that funds are missing goes to the Accounting Manager the same day. System causes go to support@aapawz.com with the source references and error records attached. Suspected fraud and legal process go to legal@aapawz.com on the day they arise.

Review cadence

The Accounting Manager reviews this runbook after every incident it is used for, adds the new check the incident produced, and reviews the whole standard quarterly.