> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chift.eu/llms.txt
> Use this file to discover all available pages before exploring further.

# POS reporting

You build a reporting product. Your end-users connect their point-of-sale systems and expect to see their sales performance in your tool: turnover by location, revenue per product category, busiest periods, payment method breakdown.

This article covers what data the POS API exposes and how to use it for reporting.

## Core concepts

### Orders

An [order](/unified-apis/pos/concepts/order) records what a customer selected at the till, with line items, products, payment methods, and customer links. Use orders for transaction-level detail.

### Closures

A [closure](/unified-apis/pos/concepts/closure) is the end-of-day summary for one location. It bundles all finalized sales since the last closure into one record.

For daily or period-based reporting, closures provide a ready-to-use aggregation. For transaction-level detail, use individual orders.

### Locations

A POS connection covers one or more [locations](/unified-apis/pos/concepts/location). If an end-user operates several stores, each location has its own sales, closures, and products. Filter by location to report per store, or aggregate across locations for a group view.

### Products and categories

A [product](/unified-apis/pos/concepts/product) carries a category. Categories are how revenue naturally groups: food versus drinks, services versus goods. For reporting, they let your end-users see which parts of their business drive turnover.

***

## Reporting scenarios

The POS API supports the following reporting use cases.

**Period performance.** [Closures](/unified-apis/pos/concepts/closure) give daily totals per location, already aggregated. For transaction-level detail, use individual [orders](/unified-apis/pos/concepts/order) filtered by date range.

**Revenue by category.** Order lines reference [products](/unified-apis/pos/concepts/product), which belong to product categories. Join them to show which parts of the business drive turnover: food versus drinks, services versus goods.

**Payment breakdown.** Each order records how the customer paid. Aggregate by payment method to show the split across cash, card, and digital wallets. This is useful for cash management and reconciliation.

**Location comparison.** Filter or group orders and closures by [location](/unified-apis/pos/concepts/location) to benchmark stores against each other, or roll up across all locations for a group view.

**Customer analysis.** When the POS stores buyer records, orders link to [customers](/unified-apis/pos/concepts/customer). Use that link for loyalty tracking or spend analysis per customer.

***

## What you build

With the [POS API](/unified-apis/pos/pos), you pull the data your reporting product needs. No configuration choices belong to the end-user beyond connecting their POS system.

You build the data pipeline (fetching, scheduling, storing) and the reporting views (charts, tables, exports). Chift handles the connector differences: the same API calls work across all connected POS systems.