POS auto-posting to journals

esaFiskaly's central promise for SMEs: the cashier never needs to understand accounting. Every POS transaction becomes a balanced journal automatically, with COGS, inventory, and tax impact — all within a single database transaction.

This page explains what happens on the accounting side every time a cashier hits Pay.

What fires when the cashier clicks "Pay"

Every step runs inside one PostgreSQL transaction. If any step fails — insufficient stock, unseeded COGS account, anything — the whole transaction rolls back. The ledger never lands in a half-applied state.

The journals that get created

For an IDR 25,000 coffee sale (non-luxury, PKP), esaFiskaly auto-posts two journals together:

Sales journal

Dr. Cash / QRIS Receivable     25,000
   Cr. Revenue                     22,523
   Cr. VAT Out                      2,477

VAT Out 2,477 = DPP Nilai Lain (11/12 × 25,000) × 12% = effective 11% per PMK 131/2024.

COGS journal (computed from weighted-average cost / FIFO):

Dr. Cost of Goods Sold          8,500
   Cr. Merchandise Inventory       8,500

Both journals are always balanced — debits and credits are derived from product configuration, never typed in by hand.

Account mapping

The system uses smart account-mapping presets seeded into the standard Indonesian Chart of Accounts. The short table:

You can override the mapping per product or per category when your business needs more specific accounts.

Step-by-step

1. 1

   Cashier builds the cart

2. 2

   Scan barcode or pick from the catalog. The screen shows total, VAT (if PKP), and change.

3. 3

   Cashier chooses a payment method

4. 4

   Cash, QRIS, card, or split. Each method maps to a different cash / receivable account in the Chart of Accounts.

5. 5

   Backend runs a single transaction

6. 6

   Inside one BEGIN ... COMMIT:

7. 7
   • Stock decremented per line (FIFO or weighted-average).
   • COGS per line computed from the relevant cost basis.
   • Sales journal and COGS journal are created and immediately posted.
   • Tax record created: PKP tenants get a faktur pajak draft (if digital invoicing is on); UMKM PP 55/2022 tenants get a PPh Final 0.5% record.
8. 8

   Settlement (QRIS / card)

9. 9

   Non-cash payments create a receivable journal. When the funds settle (T+1 or T+2), the Reconciliation module matches the receivable against bank cash.

10. 10

    Audit log is written

11. 11

    The POST request is recorded in audit_logs (immutable) with tenant_id, user_id, request body up to 64 KiB, and timestamp — inside the same per-request transaction, so an audit row never outlives a rolled-back ledger change.

Validation before any journal posts

esaFiskaly refuses nonsensical journals before they hit the ledger:

• Sum of debits = sum of credits — a 1-rupiah mismatch is rejected.
• Account must belong to your tenant — defence in depth, even though RLS is FORCEd.
• Tax rates come from decimal-string literals — no float drift; 11% is 0.11, not 0.10999999....
• Hard cap at 1 trillion rupiah per invoice line — sanity check against an extra-zero typo.

FAQ

See also

• POS → Inventory → Journal flow for the end-to-end operational path.
• VAT & DPP Nilai Lain (PMK 131/2024) for the VAT mechanism.
• Inventory adjustment for stock corrections outside the POS path.