> ## 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.

# Closure

> What a POS closure is, how Chift determines whether a day is open or closed, and how to fetch a day's orders once it is closed.

### Definition

A closure is the end-of-day summary for a point-of-sale location. It aggregates all sales, payments, and totals for a specific day.

### Purpose

Closures provide the daily totals used for accounting reconciliation. They mark the boundary between one business day and the next.

### Relationships

* A closure belongs to a location.
* It summarizes the sales and payments of that day.

### Endpoints

| Method | Endpoint                                                                                                          | Description                                  |
| ------ | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| GET    | [Get closure info for a specific day](/api-reference/endpoints/point-of-sale/get-closure-info-for-a-specific-day) | Retrieve closure information for a given day |

***

## Why it matters

In physical retail and hospitality, a "closure" is the everyday act of **ending a business day**: staff count the cash drawer, reconcile payments, and formally close the till or POS session. Once that happens, the sales recorded for that period are considered final: no more edits, refunds, or additions are expected.

This matters for anyone building on POS data because orders can still change right up until that moment. Syncing that data too early — for example into an accounting system — **risks pulling in numbers that aren't final yet**.

The `GET /pos/closures/{date}` endpoint answers a simple business question: **is this day's data safe to use yet?** `open` means the day isn't finalized and orders may still change; `closed` means the day is done and its orders can be treated as final.

Not every POS software formalizes this the same way. Some have a **real closing action** performed by staff — a Z-report, an end-of-shift close, a session close — that Chift can check directly. Others never require this step at all: transactions simply accumulate, with no explicit moment when a day is marked "done." For those, Chift estimates whether a day is likely finished based on how much time has passed, since there's no native signal to rely on.

### Closure detail

In addition to the `status`, the response includes a `closures` array (when made available by the connector) with the detail of each closure found for the requested date: its `id`, `total`, `tax_amount`, and `payments` and `taxes` breakdown.

This array is **only populated for connectors with native closure data**. For **connectors without native closures**, `closures` **is always empty**, since there's no underlying closure record to detail. See [Get closure info for a specific day](/api-reference/endpoints/point-of-sale/get-closure-info-for-a-specific-day) for more details.

***

## Native closure connectors

Some POS systems track their own end-of-day closure (a Z-ticket, a shift document, a session, etc.). For these connectors, Chift checks whether that native closure exists for the requested date and returns its status directly. **No inference is applied**.

The rule is the same across all native connectors:

* A date that is today or in the future always returns `open`.
* Any past date returns the status of the connector's own closure record for that day.

| Connector                                       | Native closure object |
| ----------------------------------------------- | --------------------- |
| [L'Addition](/connectors/pos/laddition#closure) | Shift document        |
| [Odoo POS](/connectors/pos/odoo_pos#closure)    | Point-of-sale session |

<Note>
  Each connector's own page details the exact native object used and any connector-specific nuance. See the linked sections above.
</Note>

## Connectors without native closures

When a POS does not expose its own closure concept, Chift infers the status using a time-based rule instead:

* A date that is today or in the future returns `open`.
* A date more than 7 days in the past returns `closed`.
* For dates in between, Chift checks orders on the following days as an indicator that the requested day is settled.

Refer to each connector's own page for the exact implementation of this rule.

***

## Implementation patterns

You don't need to build separate logic for each connector. The native-versus-inferred distinction above is what Chift abstracts for you. Two patterns cover every connector:

### 1. Wait for `closed` before processing a day

Only treat a day's orders as final once `GET /pos/closures/{date}` returns `closed`. An `open` day can still receive new orders, so processing it too early risks missing data.

### 2. Fetch the day's orders the right way

Once a day is `closed`, look at the closure response to decide how to retrieve its orders:

* If the response contains one or more entries in `closures`, use each entry's `closure_id` to fetch the matching orders. A single day can have more than one closure, so pull orders for every `closure_id` returned, not just the first one.
* If `closures` is empty, fetch orders directly with `date_from` and `date_to` set to that day instead.

<Note>
  Fetching orders isn't always necessary. The closure response itself may already include the figures you're after — such as the day's total amount or taxes. Check the [Get closure info](/api-reference/endpoints/point-of-sale/get-closure-info-for-a-specific-day) reference before adding a call to `GET /pos/orders`.
</Note>