> ## 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's the concept of a Closure in Point of Sale (POS), how Chift determines whether a POS closure is open or closed, and how this differs across connectors.

## Closure

### Why does it matter?

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. An order created earlier in the day could still be voided, discounted, or corrected. 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.

The `GET /pos/closures/{date}` endpoint tells you whether the end-of-day closure for a given date has already happened. This is mainly **used before syncing orders for accounting purposes**: once a day is `closed`, its orders are considered final and safe to process.

How this status is determined depends on whether the POS itself exposes a native concept of closure.

### 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 and native data from the closure**. 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**](https://docs.chift.eu/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.

***

## What this means for your implementation

You don't need to build separate logic for each connector — the native-versus-inferred distinction above is exactly what Chift abstracts for you. Connector differs to another in how you retrieve a day's data once it's closed — that's what your implementation needs to handle.

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 itself 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. Depending on what you need, 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>