> 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.md).
# Sales data
{% hint style="info" %}
Only available in API v1.
{% endhint %}
Sales data like sales figures (turnover, discount, returns etc.), counter data and KPIs can be delivered to SameSystem in an hourly or daily format.
***
### Sales data configuration
The platform provides a flexible setup, allowing customers to configure sales data according to their business needs.
Typical configurations include:
* Sales incl. VAT
* Sales excl. VAT
* Returns
* Discounts
* Number of transactions
* Number of products sold
KPIs can be calculated based on sales data, and data can be grouped together (ex. by product categories, payment methods etc.).
Sales data fields are created and managed by supervisors or administrators in the SameSystem interface. These fields must be configured before any sales data can be submitted via the API.
Because field configurations vary between customers, integrations must reference the correct field IDs when submitting sales data.
Example of sales data configuration:
Field ids are shown in the first column. These will vary from customer to customer.
You can retrieve a list of fields and their ids from the [weekly\_balance/fields](/api-v1-reference/weekly-balance/list-weekly-balance-fields.md) endpoint.
***
### Cash register identification
A department/shop can have one or multiple cash registers, each identified by a sequential number (1, 2, 3, etc.).
#### Sending data
When sending sales data, you must specify which cash register the data belongs to using the `register_number` 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.
#### Receiving data
When receiving sales data, the `register_number` attribute defines what cash register the data belongs to.
`register_number = 0` → total sales from **all** the cash registers
`register_number = 1` → sales from the first cash register
`register_number = 2` → sales from the second cash register
`register_number = 3` → sales from the third cash register
and so on.
The `register_number = 0` is always present even though you only have one cash register.
### 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`
{% 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 %}
### Confirmation of sales data
A confirmation means that the data for a given date has been correctly inserted.
Only confirmed data will be sent to the rest of SameSystem.
Data can be inserted by the API from an external system and confirmed manually by a user. This will ensure that a human has validated that the data is correct.
It is also possible to confirm data from the API. You will probably need to fetch data to check if it is inserted correctly and then confirm.
---
# 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.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.
