> For the complete documentation index, see [llms.txt](https://docs.samesystem.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.samesystem.dev/business-guides/sales-and-budget-data/sales-data/send-sales-data.md).
# Send sales data
{% hint style="info" %}
Only available in API v1.
{% endhint %}
You can send sales data from a cash register to the Weekly balance within SameSystem.
Sales data must be submitted one day at a time, and only for a single cash register per request.
You can send daily or hourly sales data. If you need to send hourly sales data, it must be configured for each field, by an administrator in the weekly balance:
{% hint style="info" %}
You should only use the full clientToken (c-value + d-value), ex. c123d12345, as clientToken in the URL, to be sure that you send data to the correct department (d-value). If you only use c-value, it will default to the department where your API user is created.
You can get the clientToken from the [Departments ](/api-v1-reference/departments/list-departments.md)endpoint. The field is called `ctx_token`.
{% endhint %}
### Cash register identification
A department/shop can have one or multiple cash registers, each identified by a sequential number (1, 2, 3, etc.).
When sending sales data, you must specify which cash register the data belongs to using the `register_number` path parameter.
If the department/shop has only one cash register, use:
`register_number = 1`
If the department/shop has multiple cash registers, use the corresponding number:
`register_number = 2` → sales from the second cash register
`register_number = 3` → sales from the third cash register
and so on.
If no value is provided, the system will automatically use the default value:
Default: `register_number = 1`
This ensures that sales data is correctly assigned to the appropriate cash register within the department/shop.
### Date/time format for hourly sales data
Hourly sales data must be submitted using the local time of the department/shop.
{% hint style="info" %}
**AI Forecasting**
For customers using the AI Forecasting feature, sales data must be provided on an **hourly basis**. This level of granularity is required for the forecasting model to process the sales data correctly.
{% endhint %}
All timestamps must reflect the actual local time, including:
* [x] The correct time zone offset.
* [x] Daylight saving time (DST) when applicable.
Time values must be provided in the following format:
`hh:mm:ss`
No additional time zone information should be included in the timestamp itself.
Example:\
Hourly sales registered at noon should be sent as:
`12:00:00`
Hourly figures registered at 10:00:00 are the total or summary of values between 10:00:00-10:59:59.
{% hint style="warning" %}
**UTC Timestamps**
Do not send timestamps in UTC unless the department/shop’s local time is UTC.
Always convert timestamps from your source system to the department/shop’s local time before sending data.
Incorrect time conversion may result in sales being registered at the wrong hour.
{% endhint %}
### Confirm sales data
When data has been sent, you can confirm the day in the weekly balance.
Use these options to confirm/unconfirm a day:
* [Confirm sales data](/api-v1-reference/weekly-balance/confirm-daily-numbers.md)
* [Unconfirm sales data](/api-v1-reference/weekly-balance/unconfirm-daily-numbers.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.samesystem.dev/business-guides/sales-and-budget-data/sales-data/send-sales-data.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
