Demystifying POS Architecture: Transactions, Masters, and Interfaces

Every time you pick up a product, walk to a checkout counter, and watch the cashier scan a barcode, a complex piece of software springs into action in the background. In a few seconds it identifies the product, applies the right price, calculates tax, reduces the stock count, and prints a bill. This smooth experience is not magic. It is the result of a carefully organised Point of Sale (POS) system built on a clear internal structure. Once you understand how that structure is arranged, the whole world of retail technology starts to make sense.

The three-tiered structure of a POS system 🔗

A POS system is far more than the till, the card machine, and the receipt printer that most people picture. The visible hardware is just the surface. Underneath sits a layered design that captures, processes, stores, and reports on every sale reliably. Most modern systems organise this design into three distinct layers that work together: Interfaces, Masters, and Transactions.

Each layer has a clear job. The interface layer is where people and devices interact with the system. The masters layer holds the stable reference data, such as product details and pricing rules, that rarely changes. The transactions layer records the live activity of the store, every sale and every stock movement, as it happens. This kind of multi-tier design lets retail software support many types of hardware and connect cleanly to other business systems. When these three layers are well separated, the system stays organised, secure, and easy to maintain as the business grows.

Transactions: the core operational ledgers 🔗

The transaction layer is the heartbeat of the system. This is where the real-time activity of the store gets recorded. Every sale, every return, and every movement of inventory is logged here as it happens. If you want to know what the store actually did on a given day, this is the layer that holds the answer. It works through a set of operational registers, each tracking a specific kind of activity.

The stock register 🔗

The Stock Register is a live record of inventory inflows and outflows. When goods arrive from a supplier, they are logged into the system, increasing the available quantity. When items are sold, returned, transferred to another store, or written off as damaged, those movements are recorded too. Because each product is tracked by a unique code, the system can update inventory counts automatically. Every time a product is sold, the POS reduces the recorded quantity for that item, which means staff and managers can see accurate stock levels without manual counting. This automation is what prevents a store from selling something it no longer has and flags items that need reordering.

The sales register 🔗

The Sales Register handles customer billing and returns. This is the part of the system most customers actually see in action. It records the items purchased, calculates the total, applies discounts, adds tax, and generates the bill. It also manages the reverse flow when a customer returns an item, adjusting both the sale record and the stock count.

In India, this register carries an important compliance responsibility. A POS bill issued to a customer is treated as a tax invoice, so it must capture the correct details for the Goods and Services Tax regime. A compliant invoice needs to show the seller’s GSTIN, a unique serial number, item descriptions with HSN codes, the applicable tax rate, and a clear split of the tax amount. The mandatory fields for a GST invoice are defined under the CGST Rules, and a bill missing even one required detail can be treated as invalid. A well-designed sales register builds these rules in, so the right tax is captured at the moment of sale rather than corrected later.

Start of day and end of day routines 🔗

The transaction layer also manages the daily rhythm of the store through two key routines. Start of Day (SoD) is the opening process, when the system is prepared for trading. This can include loading the day’s prices and promotions, setting the opening cash balance in the drawer, and confirming that terminals are ready. End of Day (EoD) is the closing process, when the day’s activity is reconciled. The system totals up sales, counts expected cash against actual cash, and locks the records for the day. These routines create a clean boundary around each trading day, which makes reporting accurate and helps catch errors or shortfalls quickly.

Masters: the stable foundation of POS data 🔗

If transactions are the fast-moving activity, the master data is the slow-moving foundation underneath it. Masters are the reference records that change infrequently but are needed for almost every transaction. They define what the store sells, at what price, with what discounts, and who is allowed to do what. Because this data is relatively stable, it is stored separately and reused across thousands of transactions rather than being re-entered each time.

The product catalogue and SKUs 🔗

The Product Catalogue is the master list of everything the store offers. At the centre of it sits the SKU, or Stock Keeping Unit. A SKU is a unique alphanumeric code that a retailer assigns to identify and track a specific product. It often encodes useful attributes such as category, brand, size, and colour, so a code like TSH-BLK-M might represent a black t-shirt in medium. Each SKU corresponds to one distinct item, which lets the system differentiate between products and manage stock levels precisely.

The catalogue stores far more than just the code. For each SKU it holds the description, the selling price, tax category, and links to the barcode. When a barcode is scanned at the counter, the system looks up the matching SKU in the catalogue to pull the correct name and price. Good SKU discipline matters: codes should be unique, consistent in format, and free of special characters so they sync cleanly across the POS, inventory tools, and any online store. As a catalogue grows from a handful of items to thousands, a clean SKU system is what keeps inventory tracking and product lookups fast and reliable.

The promotion rules master 🔗

The Promotion Rules master is where the store configures its discount strategies. Rather than hard-coding a single discount, this master lets a retailer set up flexible, layered rules. A promotion might be a flat percentage off a category, a “buy two get one free” offer, a price reduction during a specific date range, or a bundle deal that activates only above a certain spend. Because these rules live in the masters layer, a manager can change a campaign without touching the underlying billing logic. When a transaction is processed, the sales register checks the active promotion rules and applies the correct discount automatically. This separation is what allows large retailers to run complex, frequently changing offers across many stores while keeping pricing consistent and controlled.

User management and access control 🔗

A POS system handles money, sensitive customer data, and valuable inventory records, so controlling who can do what is essential. This is the job of the User Master, which stores user accounts and the permissions attached to them. The standard approach is role-based access control, where permissions are granted to roles rather than to individuals. A cashier role might be allowed to process sales but not to change prices, while a manager role can authorise returns, apply manual discounts, or edit the product catalogue.

Role-based access and the maker-checker principle 🔗

Role-based access supports a stronger security idea known as segregation of duties. The principle is simple: no single person should be able to initiate, approve, and complete a high-risk action entirely on their own. The most common way to enforce this is the maker-checker model, sometimes called the four-eyes principle. Under this model, one person, the maker, prepares or initiates an action, while a second person, the checker, reviews and either approves or rejects it.

This concept has been a cornerstone of banking and finance for decades, and it translates neatly into retail. Consider a large discount, a price change, or a stock write-off. If one employee could both enter and approve such an action, the system would be exposed to both honest mistakes and deliberate fraud. With maker-checker in place, a sensitive action sits in a pending state until an independent, authorised person approves it. Crucially, the maker and the checker cannot be the same individual, and this rule is enforced through system-level permissions rather than left to trust. The result is a system that protects its own integrity while still keeping a clear audit trail of who did what.

Interfaces: connecting hardware and systems 🔗

The interface layer is where the POS system meets the physical world and the wider network of business software. It covers two broad categories: the hardware that staff and customers touch, and the software connections to other systems.

Core hardware interfaces 🔗

At the hardware level, a typical POS setup is built around a host computer, often a personal computer or a dedicated terminal, to which a range of input and output devices connect. These include the display, printer, scanner, and cash drawer, along with card readers and other peripherals. A touch screen lets staff select items and navigate the interface quickly, a barcode scanner reads product codes to look up the matching SKU, a receipt printer produces the bill, and a payment terminal handles card and digital transactions. Each device communicates with the POS software through a defined interface, which is why a system can support different brands and models of hardware as long as they follow the expected standards.

Integrating with ERP and external systems 🔗

The second kind of interface connects the POS to external software, and the most important of these is the link to an ERP (Enterprise Resource Planning) system. An ERP brings inventory, purchasing, finance, and reporting together in a single database. When the POS is integrated with it, data flows in both directions. Sales and stock movements captured at the counter flow up to the ERP, while updated prices, new products, and promotions flow down to the terminals. Ideally the inventory management built into the POS is integrated with an ERP platform so that information is shared seamlessly across systems.

This integration is what turns isolated checkout counters into a connected business. A central ERP can pull daily sales from every store, compare them, trigger automatic reorders when stock runs low, and feed accurate figures into financial reporting and tax returns. Many Indian retailers now favour this connected model precisely because it captures correct tax data at the source and keeps records ready for GST filing, which reduces errors and manual rework. The interface layer, in short, is what allows a single transaction at one counter to ripple cleanly through the entire organisation.

What do you think? If you were designing the user master for a chain of supermarkets, which actions would you place behind a maker-checker approval, and which would you leave to a single cashier? And as more retailers move to cloud-based, ERP-connected systems, do you think the clean separation between interfaces, masters, and transactions will become more important, or will these layers eventually blur together?

References

1. https://docs.oracle.com/cd/E12517_01/back_office/pdf/141/html/pos_impg1/architecture.htm
2. https://www.netsuite.com/portal/resource/articles/inventory-management/stock-keeping-unit-SKU.shtml
3. https://cleartax.in/s/gst-invoice
4. https://www.propelsoftware.com/glossary/stock-keeping-unit-sku
5. https://squareup.com/ca/en/the-bottom-line/operating-your-business/stock-keeping-unit
6. https://en.wikipedia.org/wiki/Maker-checker
7. https://hightable.io/iso-27001-annex-a-5-3-segregation-of-duties/
8. https://patents.google.com/patent/US20050261969A1/en