---
name: retail-and-pos-accounting-pack
description: "Use for multi-outlet and omnichannel retail accounting: SKU master, POS/day-end, cash drawer, card/mobile-money settlement, inventory costing, markdowns, promotions, refunds, returns disposition, gift cards, loyalty, shrinkage, vendor funding, private label landed cost, planogram/space profitability, and retail KPI/WBR reporting."
status: active
metadata:
portable: true
category: 11-sector-and-fund-accounting
compatible_with:
- claude-code
- codex
Retail And POS Accounting Pack
Use When
Use when a finance, accounting, reporting, controls, systems, or sector workflow needs retail-specific source events, controls, reporting views, tax touchpoints, and accounting classifications for stores, e-commerce, POS, omnichannel fulfilment, inventory, customer returns, supplier funding, or retail dashboards.
Do Not Use When
Do not use as a substitute for professional judgement, current statutory verification, full standard text, legal advice, actuarial valuation, tax opinion, or named reviewer approval where the engagement requires it.
Required Inputs
Entity profile, reporting framework, jurisdiction, functional currency, period, source events, source documents, account map, dimensions, source-register snapshot where statutory values appear, and reviewer route.
Workflow
Frame the accounting question, confirm the applicable framework, collect source evidence, apply the decision rules, create the ledger/reporting/control artefact, reconcile it to source records, and route exceptions or judgemental decisions to the named reviewer role.
Quality Standards
Framework-identified, source-evidenced, reviewer-routable, ledger-reconcilable, period-aware, and caveated where external law, standards, rates, or judgemental estimates remain pending.
Anti-Patterns
Using unsupported rates or facts, bypassing the posting service, releasing final statutory output without verified-current source-register entries, hiding judgement calls in free text, or treating illustrative examples as client facts.
Outputs
Decision memo, configured policy, posting/reporting map, reconciliation evidence, exception queue, reviewer routing record, and worked example.
References
Load references/source-basis.md, references/implementation-rules.md, and the canonical doctrine references before applying this skill.
Prerequisites
- Read doctrine/accounting-finance-doctrine.md.
- Read doctrine/references/policy-hierarchy.md.
- Read doctrine/references/ledger-invariants.md.
- Read references/source-basis.md.
- Read references/implementation-rules.md.
- Confirm framework, jurisdiction, functional currency, reporting period, entity type, and reviewer route.
Inputs
| Artifact |
Produced by |
Required? |
Validation |
| Scope and framework memo |
Engagement owner |
Required |
Names the entity, period, reporting framework, jurisdiction, and functional currency. |
| Source-event pack |
Subledger, integration, or preparer |
Required |
Source document, actor, date, period, amount, currency, account, dimension, and evidence pointer captured. |
| Policy and judgement log |
Controller or preparer |
Required for judgemental items |
Distinguishes standard requirement, management judgement, estimate, and inference. |
| Source-register snapshot |
Country-pack owner |
Required when statutory values appear |
Entries are verified-current or explicitly blocked from final output. |
| Reviewer route |
Doctrine owner |
Required |
Owner role and reviewer role are named before release. |
Outputs
| Artifact |
Consumed by |
Acceptance evidence |
| Decision memo |
Controller and reviewer |
States the question, framework, source basis, decision, caveat, and reviewer route. |
| Posting or reporting map |
GL, close, reporting, or integration owner |
Maps source event to account, dimension, period, currency, and evidence pointer. |
| Reconciliation workpaper |
Close owner and auditor |
Ties source records to subledger, control account, report line, and exception queue. |
| Exception register |
Controller and reviewer |
Captures blocked, missing, stale, disputed, or judgemental items with owner and due date. |
| Worked example |
Implementer and tester |
Reproducible example under examples/worked-example.md; no client facts implied. |
Retail Event Matrix
| Retail event |
Accounting/control question |
Required evidence |
| POS sale, online sale, split tender |
Has the sale been decomposed by tender, tax, discount, channel, store, SKU/category, and source document? |
Receipt/order, tender lines, tax code, discount reason, cashier/user, settlement batch. |
| Cash drawer close |
Does counted cash reconcile to POS expected cash with approved variance handling? |
Opening float, POS cash sales, paid-in/out, count sheet, variance reason, approver, deposit evidence. |
| Card/mobile-money settlement |
Do gateway/mobile-money/card batches reconcile to POS/order tenders and bank deposits? |
Provider batch, transaction IDs, fees, refunds, chargebacks, bank statement, exception queue. |
| Refund or exchange |
Is the refund linked to original sale and approved where policy requires? |
Original receipt/order, return authorisation, inspection, tender reversal, approval, customer credit note where applicable. |
| Return disposition |
Does the item return to sellable stock, quarantine, repair, vendor return, donation, or disposal with valuation impact recorded? |
Inspection result, disposition code, stock movement, write-down or recovery evidence. |
| Markdown |
Is the price reduction authorised, effective-dated, reflected in margin reporting, and reviewed for stock valuation effects? |
Markdown event, SKU/category, original price, markdown price, reason, approver, effective period. |
| Promotion/coupon/manual discount |
Is the discount eligible, stack-controlled, funded source identified, and margin leakage visible? |
Promotion setup, coupon rule, eligibility evidence, funding source, cashier override approval. |
| Gift card/store credit/customer wallet |
Is issuance and redemption tracked as a liability or customer balance until redeemed/expired according to policy? |
Issuance source, redemption event, expiry policy, breakage judgement route, balance report. |
| Loyalty points/rewards |
Are points/rewards issued, redeemed, expired, and measured under an approved policy? |
Programme policy, issuance/redemption events, customer balance, liability or marketing-cost route. |
| Stock receipt/transfer/adjustment/count |
Does the inventory subledger reconcile to stock evidence and GL control account? |
PO/GRN/transfer/count sheet, variance reason, costing method, approver, posting batch. |
| Shrink/loss incident |
Is the loss classified, investigated, approved, and posted or reserved through a controlled route? |
Incident report, count variance, CCTV/evidence pointer where applicable, investigator, approval. |
| Vendor rebate/allowance/co-op/scanback |
Is the claim supported by agreement terms and source sales/purchase/promotional evidence? |
Vendor agreement, claim basis, transaction extract, invoice/credit note, dispute and recovery status. |
| Private label landed cost |
Are freight, duty, packaging, inspection, and wastage allocated to inventory or expense using a documented basis? |
Supplier invoice, freight/duty documents, cost allocation workpaper, quality release/hold. |
| Retail KPI/WBR metric |
Does the dashboard metric drill back to source transactions and reconciliation status? |
Metric dictionary, source lineage, refresh timestamp, reconciliation state, action owner. |
Decision Rules
- Identify the applicable reporting framework and scope boundary before recognition, measurement, disclosure, control, or workflow design.
- Treat the source document as the unit of evidence; every output must drill back to source document, actor, period, account, dimension, and audit log.
- If a posting is required, route it through the canonical posting service and enforce balance, period state, currency, idempotency, and reversal rules.
- If statutory, tax, payroll, exchange-rate, or fiscal-device values appear, use only verified-current source-register entries or block final release.
- Record judgemental decisions separately from facts, with reviewer role, evidence considered, rejected alternatives, and caveats.
- Reconcile operational records to the GL control account before reporting, settlement, close sign-off, or external disclosure.
- Maintain an exception register for missing evidence, stale source-register values, unsupported framework assumptions, unresolved estimates, and review blockers.
- Do not promote illustrative examples, assumed facts, or generic rates into client output.
- For retail workflows, separate operational status from accounting status. A return can be operationally accepted while accounting remains pending until inspection, refund, stock disposition, and settlement evidence reconcile.
- For markdowns, promotions, discounts, and coupons, preserve the original price, applied price, funding source, reason code, and approval route so margin analysis and audit review are possible.
- For vendor funding, do not recognise or report recovery without agreement evidence, claim basis, source transactions, and dispute status.
- For retail dashboards and weekly business review outputs, block summary-only financial KPIs that lack drilldown to source events and reconciliation state.
Acceptance Evidence
- references/source-basis.md lists the official or canonical sources used for this skill and assigns source tiers.
- references/implementation-rules.md translates the source basis into local doctrine rules, blocked-output rules, and review gates.
- examples/worked-example.md shows a minimal evidence-backed artefact, posting/reporting impact, reconciliation, and reviewer route.
- references/retail-event-controls.md defines the retail event/control matrix and acceptance fixtures for markdowns, returns, shrink, vendor funding, loyalty/gift cards, POS settlement, and WBR dashboards.
- The skill is active for doctrine use, but client-specific statutory/legal final output still requires current source-register verification and reviewer approval.
Anti-Patterns
- Treating draft client facts, example figures, or unsupported management assumptions as verified evidence.
- Posting directly to the ledger without the posting service or without an idempotency key.
- Releasing final statutory output from a stale, missing, or unverified source-register entry.
- Combining multiple judgement calls into a single unexplained adjustment.
- Omitting the exception register because the amount is small.
- Using this skill without loading its source basis and implementation rules.
Files
- references/source-basis.md
- references/implementation-rules.md
- references/retail-event-controls.md
- examples/worked-example.md
Review Metadata
| Field |
Value |
| Owner role |
Doctrine owner |
| Reviewer roles |
Sector specialist; controller; tax reviewer where statutory values appear |
| Last reviewed |
2026-06-25 |
| Next review due |
2026-12-25 |
| Release state |
Active doctrine content; client-specific release remains subject to reviewer approval and verified-current statutory sources where applicable. |
| Caveat |
No human reviewer name has been fabricated. Record named reviewer sign-off in the engagement or release log when obtained. |
Last reviewed: 2026-06-25. Next review due: 2026-12-25.
1---2name: retail-and-pos-accounting-pack3description: ---4---5---6name: retail-and-pos-accounting-pack7description: "Use for multi-outlet and omnichannel retail accounting: SKU master, POS/day-end, cash drawer, card/mobile-money settlement, inventory costing, markdowns, promotions, refunds, returns disposition, gift cards, loyalty, shrinkage, vendor funding, private label landed cost, planogram/space profitability, and retail KPI/WBR reporting."8status: active9metadata:10 portable: true11 category: 11-sector-and-fund-accounting12 compatible_with:13 - claude-code14 - codex15---1617# Retail And POS Accounting Pack1819<!-- dual-compat-start -->20## Use When2122Use when a finance, accounting, reporting, controls, systems, or sector workflow needs retail-specific source events, controls, reporting views, tax touchpoints, and accounting classifications for stores, e-commerce, POS, omnichannel fulfilment, inventory, customer returns, supplier funding, or retail dashboards.2324## Do Not Use When2526Do not use as a substitute for professional judgement, current statutory verification, full standard text, legal advice, actuarial valuation, tax opinion, or named reviewer approval where the engagement requires it.2728## Required Inputs2930Entity profile, reporting framework, jurisdiction, functional currency, period, source events, source documents, account map, dimensions, source-register snapshot where statutory values appear, and reviewer route.3132## Workflow3334Frame the accounting question, confirm the applicable framework, collect source evidence, apply the decision rules, create the ledger/reporting/control artefact, reconcile it to source records, and route exceptions or judgemental decisions to the named reviewer role.3536## Quality Standards3738Framework-identified, source-evidenced, reviewer-routable, ledger-reconcilable, period-aware, and caveated where external law, standards, rates, or judgemental estimates remain pending.3940## Anti-Patterns4142Using unsupported rates or facts, bypassing the posting service, releasing final statutory output without verified-current source-register entries, hiding judgement calls in free text, or treating illustrative examples as client facts.4344## Outputs4546Decision memo, configured policy, posting/reporting map, reconciliation evidence, exception queue, reviewer routing record, and worked example.4748## References4950Load references/source-basis.md, references/implementation-rules.md, and the canonical doctrine references before applying this skill.51<!-- dual-compat-end -->5253## Prerequisites5455- Read doctrine/accounting-finance-doctrine.md.56- Read doctrine/references/policy-hierarchy.md.57- Read doctrine/references/ledger-invariants.md.58- Read references/source-basis.md.59- Read references/implementation-rules.md.60- Confirm framework, jurisdiction, functional currency, reporting period, entity type, and reviewer route.6162## Inputs6364| Artifact | Produced by | Required? | Validation |65|---|---|---|---|66| Scope and framework memo | Engagement owner | Required | Names the entity, period, reporting framework, jurisdiction, and functional currency. |67| Source-event pack | Subledger, integration, or preparer | Required | Source document, actor, date, period, amount, currency, account, dimension, and evidence pointer captured. |68| Policy and judgement log | Controller or preparer | Required for judgemental items | Distinguishes standard requirement, management judgement, estimate, and inference. |69| Source-register snapshot | Country-pack owner | Required when statutory values appear | Entries are verified-current or explicitly blocked from final output. |70| Reviewer route | Doctrine owner | Required | Owner role and reviewer role are named before release. |7172## Outputs7374| Artifact | Consumed by | Acceptance evidence |75|---|---|---|76| Decision memo | Controller and reviewer | States the question, framework, source basis, decision, caveat, and reviewer route. |77| Posting or reporting map | GL, close, reporting, or integration owner | Maps source event to account, dimension, period, currency, and evidence pointer. |78| Reconciliation workpaper | Close owner and auditor | Ties source records to subledger, control account, report line, and exception queue. |79| Exception register | Controller and reviewer | Captures blocked, missing, stale, disputed, or judgemental items with owner and due date. |80| Worked example | Implementer and tester | Reproducible example under examples/worked-example.md; no client facts implied. |8182## Retail Event Matrix8384| Retail event | Accounting/control question | Required evidence |85|---|---|---|86| POS sale, online sale, split tender | Has the sale been decomposed by tender, tax, discount, channel, store, SKU/category, and source document? | Receipt/order, tender lines, tax code, discount reason, cashier/user, settlement batch. |87| Cash drawer close | Does counted cash reconcile to POS expected cash with approved variance handling? | Opening float, POS cash sales, paid-in/out, count sheet, variance reason, approver, deposit evidence. |88| Card/mobile-money settlement | Do gateway/mobile-money/card batches reconcile to POS/order tenders and bank deposits? | Provider batch, transaction IDs, fees, refunds, chargebacks, bank statement, exception queue. |89| Refund or exchange | Is the refund linked to original sale and approved where policy requires? | Original receipt/order, return authorisation, inspection, tender reversal, approval, customer credit note where applicable. |90| Return disposition | Does the item return to sellable stock, quarantine, repair, vendor return, donation, or disposal with valuation impact recorded? | Inspection result, disposition code, stock movement, write-down or recovery evidence. |91| Markdown | Is the price reduction authorised, effective-dated, reflected in margin reporting, and reviewed for stock valuation effects? | Markdown event, SKU/category, original price, markdown price, reason, approver, effective period. |92| Promotion/coupon/manual discount | Is the discount eligible, stack-controlled, funded source identified, and margin leakage visible? | Promotion setup, coupon rule, eligibility evidence, funding source, cashier override approval. |93| Gift card/store credit/customer wallet | Is issuance and redemption tracked as a liability or customer balance until redeemed/expired according to policy? | Issuance source, redemption event, expiry policy, breakage judgement route, balance report. |94| Loyalty points/rewards | Are points/rewards issued, redeemed, expired, and measured under an approved policy? | Programme policy, issuance/redemption events, customer balance, liability or marketing-cost route. |95| Stock receipt/transfer/adjustment/count | Does the inventory subledger reconcile to stock evidence and GL control account? | PO/GRN/transfer/count sheet, variance reason, costing method, approver, posting batch. |96| Shrink/loss incident | Is the loss classified, investigated, approved, and posted or reserved through a controlled route? | Incident report, count variance, CCTV/evidence pointer where applicable, investigator, approval. |97| Vendor rebate/allowance/co-op/scanback | Is the claim supported by agreement terms and source sales/purchase/promotional evidence? | Vendor agreement, claim basis, transaction extract, invoice/credit note, dispute and recovery status. |98| Private label landed cost | Are freight, duty, packaging, inspection, and wastage allocated to inventory or expense using a documented basis? | Supplier invoice, freight/duty documents, cost allocation workpaper, quality release/hold. |99| Retail KPI/WBR metric | Does the dashboard metric drill back to source transactions and reconciliation status? | Metric dictionary, source lineage, refresh timestamp, reconciliation state, action owner. |100101## Decision Rules1021031. Identify the applicable reporting framework and scope boundary before recognition, measurement, disclosure, control, or workflow design.1042. Treat the source document as the unit of evidence; every output must drill back to source document, actor, period, account, dimension, and audit log.1053. If a posting is required, route it through the canonical posting service and enforce balance, period state, currency, idempotency, and reversal rules.1064. If statutory, tax, payroll, exchange-rate, or fiscal-device values appear, use only verified-current source-register entries or block final release.1075. Record judgemental decisions separately from facts, with reviewer role, evidence considered, rejected alternatives, and caveats.1086. Reconcile operational records to the GL control account before reporting, settlement, close sign-off, or external disclosure.1097. Maintain an exception register for missing evidence, stale source-register values, unsupported framework assumptions, unresolved estimates, and review blockers.1108. Do not promote illustrative examples, assumed facts, or generic rates into client output.1119. For retail workflows, separate operational status from accounting status. A return can be operationally accepted while accounting remains pending until inspection, refund, stock disposition, and settlement evidence reconcile.11210. For markdowns, promotions, discounts, and coupons, preserve the original price, applied price, funding source, reason code, and approval route so margin analysis and audit review are possible.11311. For vendor funding, do not recognise or report recovery without agreement evidence, claim basis, source transactions, and dispute status.11412. For retail dashboards and weekly business review outputs, block summary-only financial KPIs that lack drilldown to source events and reconciliation state.115116## Acceptance Evidence117118- references/source-basis.md lists the official or canonical sources used for this skill and assigns source tiers.119- references/implementation-rules.md translates the source basis into local doctrine rules, blocked-output rules, and review gates.120- examples/worked-example.md shows a minimal evidence-backed artefact, posting/reporting impact, reconciliation, and reviewer route.121- references/retail-event-controls.md defines the retail event/control matrix and acceptance fixtures for markdowns, returns, shrink, vendor funding, loyalty/gift cards, POS settlement, and WBR dashboards.122- The skill is active for doctrine use, but client-specific statutory/legal final output still requires current source-register verification and reviewer approval.123124## Anti-Patterns125126- Treating draft client facts, example figures, or unsupported management assumptions as verified evidence.127- Posting directly to the ledger without the posting service or without an idempotency key.128- Releasing final statutory output from a stale, missing, or unverified source-register entry.129- Combining multiple judgement calls into a single unexplained adjustment.130- Omitting the exception register because the amount is small.131- Using this skill without loading its source basis and implementation rules.132133## Files134135- references/source-basis.md136- references/implementation-rules.md137- references/retail-event-controls.md138- examples/worked-example.md139140## Review Metadata141142| Field | Value |143|---|---|144| Owner role | Doctrine owner |145| Reviewer roles | Sector specialist; controller; tax reviewer where statutory values appear |146| Last reviewed | 2026-06-25 |147| Next review due | 2026-12-25 |148| Release state | Active doctrine content; client-specific release remains subject to reviewer approval and verified-current statutory sources where applicable. |149| Caveat | No human reviewer name has been fabricated. Record named reviewer sign-off in the engagement or release log when obtained. |150151Last reviewed: 2026-06-25. Next review due: 2026-12-25.
peterbamuhigire