# Accounting policy decisions required before GL posting

Status: repository evidence and engineering recommendations only. Nothing in this document is approved accounting policy. Rates, mappings, and treatments require owner approval before deployment.

## Repository evidence

- POS `ProcessPOS` creates an operational SO, stock deduction, invoice and (for immediate methods) payment in one transaction. QRIS leaves an unpaid invoice until a verified provider notification/status lookup settles it.
- Invoice payments support partial amounts and multiple payment rows per invoice; finance updates invoice/SO balances transactionally. No GL journal is written.
- POS accepts one payment method per request. Methods include cash, transfer, giro, cheque, QRIS and card; split tender has no input representation.
- Returns are separate records with pro-rata refund based on original selling-price snapshots. Accepted goods restock; damaged goods do not. Cash return may update an open drawer. Tax/discount allocation and quarantine policy are unresolved.
- COA includes cash, bank, AR, inventory, AP, sales revenue and expenses. No verified operational output-tax payable or dedicated COGS mapping was found. Separate `cash_accounts` and COA accounts exist without an authoritative payment-to-COA map.
- Sales lines snapshot price/discount, not unit cost. Stock movements contain quantities but no cost. GR lines contain quantities; PO lines carry unit prices. `products.purchase_price` is mutable and used by current valuation reports.

## Decisions

| Policy | Current behavior | Options | Recommendation | Required approval / risk |
|---|---|---|---|---|
| POS revenue recognition | SO/invoice/payment operationally created at checkout; no GL | Checkout/handover vs fulfillment event | Recognize when the approved goods-transfer event occurs. Do not treat payment settlement as revenue recognition. | Owner defines event per channel; wrong timing misstates revenue and inventory. |
| Invoice and collection | Invoice and payment are separate; invoice supports partials | Revenue at invoice, fulfillment, or payment | Separate sale recognition from collection; later collections settle AR. | Confirm invoice/fulfillment event by channel. |
| POS collections | Immediate methods write payment row; QRIS deferred | Sale-plus-payment versus distinct entries | Distinct posting events even when one DB transaction; payment ID is collection source. | Approve mapping and split-tender support contract. |
| QRIS | Open invoice until verified capture; gateway refs persisted | Capture to gateway clearing; bank payout later | Separate capture/clearing from bank settlement. Capture must not book revenue twice. | Define provider capture, payout, fee, refund treatment. |
| Cash/bank/clearing | `cash_accounts` exists; not mapped authoritatively to COA | Explicit mapping table or validated payment defaults | Explicit backend mapping, optionally store-scoped. Never infer account from payment method/name/order. | Approve each mapping and outlet scope. |
| Revenue accounts | `4000.01` Mart and `4000.02` Depot exist | Product/category/channel mapping or one account | Explicit product/category mapping in backend. | Approve account mapping and shipping treatment. |
| Output tax | Regular order has a tax percentage; POS currently computes none | Configured tax, tax-inclusive pricing, or no tax | Configure rate, basis, rounding and payable account before posting. Do not infer legal rates. | Owner/tax advisor approval. |
| Discounts/vouchers | Line/order discounts and membership snapshots exist | Contra-revenue, expense, or allocation | Preserve discount separately and use one approved treatment for sale and return. | Approve stacking, funding, tax basis and rounding. |
| Partial/failed payments | Partial invoice payments supported; QRIS may remain unpaid | AR on open balance; payment-in-transit for pending | Each successful collection posts once; failures post nothing; retain invoice balance. | Approve method accounts and provider states representing capture. |
| Returns/refunds | Pro-rata operational refund; accepted goods restock | Reverse revenue/tax and cost; store-credit liability | Reference original invoice/payment/line; restore original recorded cost for accepted goods. | Approve tax/promotion/store-credit/damaged policies. |
| Void/reversal/backdate | Posted journals reverse; period guard active | Current open period vs reopen original | Preserve original; create linked reversal/adjustment with reason, actor and explicit date. | Approve reversal period and reopening authority. |
| Inventory cost | Current reports use quantity × current purchase price | Moving weighted average or FIFO | No final method until cost events, negative stock, return and backdate rules are approved. | Controller/owner approval; historical cost may not be reconstructible. |
| Receipt/invoice | GR stores quantities, PO stores unit prices; GR accrual is advisory draft | Inventory at receipt; AP at invoice; GR/IR clearing | Match receipt and supplier invoice without double-recognizing AP; cost from approved cost method. | Approve landed cost, tax, discount, invoice lifecycle and variance handling. |
| Stock adjustment | Opname updates stock; hook posts supplied variance value | Shrinkage, write-off, gain, quarantine | Require reason/approval/source ID; calculate value from cost ledger, not client/current price. | Approve reasons/accounts and gains policy. |
| Supplier payment | PO payment and journal hook use separate transactions | Shared transaction/outbox with idempotent source | Stable supplier-payment ID; atomic PO/AP/journal outcome. | Approve partial payment, bank matching and identity. |
| Reconciliation | Close checks GL balance/drafts; no source subledger reconciliation | Read-only exception report before correction | Show source balance, control account, difference, reference and timing; never auto-plug. | Approve control accounts and resolution rules. |

## Inventory history readiness

Current schema cannot support defensible historical FIFO or moving-average reconstruction:

- `stock_movements` has quantities/references but no unit or extended cost; GR path does not guarantee complete movements.
- GR quantities can link to PO price, but no immutable received unit cost/landed-cost event is preserved.
- Sales lines have no cost snapshot or layer consumption.
- Product purchase price is mutable; historical stock-value reports can change after edits.
- Returns cannot restore the original inventory cost from existing records.

Recommended cutover: select method and effective-date/backdate/negative-stock rules; take an approved physical quantity and unit-cost opening balance per product/warehouse; preserve evidence and approval; do not fabricate old cost layers from current product price; start immutable cost-event tracking prospectively. Reconcile value and quantity to GL without automatic balancing journals.

## Approvals required

Revenue-recognition event per channel; tax treatment/rates; discount/voucher policy; cash/bank/clearing map; revenue/COGS/inventory accounts; cost method and cutover; return/store-credit/damaged-goods treatment; reversal dates and permissions; supplier payment source identity; reconciliation accounts and escalation rules.