Revenue module
POINT-OF-SALE / MODULEPoint of Sale
Every checkout deducts real inventory in the same database transaction as the sale — no nightly sync, no phantom stock.
Checkout to Inventory and Finance
- 01
Ring up
A multi-line sale is built with mixed-tender payment.
- 02
Checkout
The sale is completed under an idempotency key, posting a real stock deduction in the same transaction.
- 03
Handle exceptions
Returns are line-level and policy-gated; price overrides require the override permission.
- 04
Close shift
Cash and other tenders are counted; server-computed variance is recorded per payment method.
What it is
The Vercentlabs Point of Sale module is governed retail checkout — cashiers ring up sales, take mixed-tender payment, and reconcile cash, with every sale deducting real inventory in the same database transaction as the sale itself.
Module atlas / operating conditions
Why Point of Sale becomes difficult in fragments
Disconnect between floor sales and back-office stock
The register says one thing is in stock; the warehouse system says another, and nobody's sure which to trust until a physical count.
Unauthorized over- or under-charging
A price gets overridden at the register with no clear record of who approved it or why.
Indefensible end-of-day cash reconciliation
Cash counts don't match the expected total, and there's no structured variance record to explain why.
Operating outcomes
What changes when Point of Sale shares one system of record
Inventory that's never out of sync
Every checkout posts a stock deduction in the same transaction as the sale — not a nightly batch job that can fail silently.
Controlled price overrides
A price-override permission gate means only authorized roles can change a price at the register.
Defensible cash reconciliation
Shift close computes expected-vs-counted variance per payment method automatically.
Capability architecture
The module, decomposed by operating capability.
5 capability groups organised by the way the product works, not as a flat marketing feature wall.
Checkout & cart completion
The core sale transaction.
- 01Multi-line sale with mixed-tender payment
- 02Idempotency-key-protected checkout
Shift & cash-drawer control
Controlling who's operating a terminal and reconciling the drawer.
- 01Opening float and close-with-variance calculation
- 02One open shift per terminal enforced by a unique index
Returns & refunds
Handling a return without losing control.
- 01Line-level returns
- 02Policy-gated return approval
Store/terminal/pricing setup
Configuring how a store and its terminals operate.
- 01Store and terminal configuration
- 02Pricing setup
Reconciliation
Closing the day with a defensible number.
- 01Per-payment-method expected/counted/variance tracking
Primary operating sequence
A transaction-level view of how work progresses through Point of Sale.
See it work
Checkout to Inventory and Finance
The ordered process a real Point of Sale workflow follows inside Vercentlabs.
Trigger
A cashier opens a shift with a starting float.
- Ring up
A multi-line sale is built with mixed-tender payment.
- Checkout
The sale is completed under an idempotency key, posting a real stock deduction in the same transaction.
- Handle exceptions
Returns are line-level and policy-gated; price overrides require the override permission.
- Close shift
Cash and other tenders are counted; server-computed variance is recorded per payment method.
Approvals
- 01Price overrides require a dedicated permission gate.
- 02Returns above policy thresholds require approval.
Automated actions
- 01Real-time stock deduction at checkout
- 02Server-computed cash-variance calculation at shift close
Connected modules in this workflow
Outcome
A completed sale with inventory already correct and a cash drawer that reconciles to a real, computed variance — not a guess.
Operational proof
Point of Sale, documented as an operating system.
Capability architecture
5 groups
Grouped by how the module is actually structured.
Primary operating sequence
Checkout to Inventory and Finance
Rendered above as an ordered process rather than a feature collage.
Connected system
2 modules
Adjacent modules are linked through the operating model on this page.
Business outcome
Inventory that's never out of sync
Every checkout posts a stock deduction in the same transaction as the sale — not a nightly batch job that can fail silently.
Ready to see Point of Sale running on your own data?
Book a DemoSystem map
Point of Sale does not operate alone.
The handoffs below are part of the operating model, not decorative cross-sells.
Output register
What Point of Sale tells operators and managers
Sales, shift status, and cash variance
Audience / Shift supervisors, store admins
Rule register
What the module can run on its own
Stock is deducted in the same database transaction as the sale, not a separate nightly sync.
Expected-vs-counted variance is calculated automatically at shift close, per payment method.
Returns above policy thresholds route to approval automatically.
Control register
How Point of Sale stays governed
Module-specific controls shown separately from the platform-wide security architecture.
Price overrides require a dedicated permission, not a general 'cashier' role.
Store and terminal data is isolated at the database level.
A duplicate checkout request can't create a duplicate sale.
What to plan before going live.
- 01
Store, terminal, and pricing configuration is set up per location before go-live.
- 02
Cash-drawer float amounts and variance-tolerance policy are agreed before rollout.
- 03
Return policy thresholds are configured to match how much discretion you want at the register.
- 04
Point of Sale is explicitly excluded from the mobile module catalog — it's a desktop/terminal workflow.
Buyer questions
Questions teams ask about Point of Sale
Does a POS sale automatically reduce warehouse inventory?
Yes — every checkout posts a real stock deduction in the same database transaction as the sale, with no nightly sync step.
Does a POS sale automatically create a Sales order or Accounting invoice?
Not automatically — the linking columns exist on the POS sale record, but they're not populated by an automated process today. Treat POS as inventory-integrated, not fully books-integrated, until that link ships.
Is Point of Sale available on a mobile phone?
No — Point of Sale is explicitly excluded from the mobile module catalog. It's a desktop/terminal workflow.
Continue the operating map