Receipt fields: contents and reference tables

Here is the complete contents of the receipt object (in correction receipts it is called correction) and all the value reference tables the Cash Server API accepts. Everything described below is checked at the intake: a receipt that fails the check returns error 32, and the error text names the specific field.

1. Structure#

{
  "client":   { "email": "buyer@example.com" },
  "company":  { "email": "shop@example.com", "sno": "usn_income",
                "inn": "7736570901", "payment_address": "https://shop.example" },
  "items":    [ /* 1…100 items */ ],
  "payments": [ /* at least one payment */ ],
  "vats":     [ { "type": "vat20", "sum": 416.67 } ],
  "total": 2500.00,
  "cashier": "Ivanov I.I.",
  "cashier_inn": "123456789047",
  "additional_check_props": "Order #10421",
  "additional_user_props": { "name": "Manager", "value": "Petrov" },
  "internet": true,
  "device_number": "web-1"
}

Required minimum: client (for sales operations), company, items, payments, total.

Monetary Rules#

Amounts are passed as numbers, not strings. An item is calculated as price × quantity, but the item total is taken from sum — if you have a discount on an item, put the actual cost into sum.

2. client — Customer#

For online payments, the receipt is always electronic, so a receipt delivery destination is required: at least one of email / phone. If both are provided, the OFD will send the receipt to the email.

Extended attributes (name…address) are required only in specific industry cases — a regular online store only needs email or phone. Support for them depends on the cash register model: if the fiscal printer does not support them, the document will return with a driver error — the message text from the register itself (for example: "customer attributes (tags 1227/1228/1008/1256)… are not supported"), without a separate error code.

3. company — seller#

The TIN must match the TIN registered for your POS fiscal drive. A mismatch is rejected immediately upon registration: HTTP 400, error 32, the message specifies both TINs — of the receipt and the group. The document is not queued.

Taxation systems (sno)#

If the field is not passed, the default taxation system configured for your POS group is applied.

4. items — the line items#

{
  "name": "Coffee beans, 1 kg",
  "price": 1250.00,
  "quantity": 2,
  "sum": 2500.00,
  "measure": 11,
  "payment_method": "full_payment",
  "payment_object": 1,
  "vat": { "type": "vat20" },
  "user_data": "SKU A-100"
}

The payment method attribute (payment_method)#

The payment subject attribute (payment_object, a number in v5)#

An ordinary online store product is code 1; a service is 4; a marked good with a scanned code is 33.

In the v4 protocol the same field is passed as a string (commodity, service, job, payment, agent_commission, another and so on) — the historic v4 names are accepted and mapped to the modern table automatically.

The unit of measure (measure, a number in v5)#

In v4 a measurement_unit string is passed instead of the code ("pcs", "kg", "l", "hour"); an unrecognized string is mapped to "another unit".

VAT rates (vat.type)#

The derived rates apply to amounts that already include the tax — to advances and prepayments, for example.

The 22% and 22/122 rates require a cash register whose firmware knows the new rate. Some older-generation models physically do not accept it — check with your service centre.

5. payments — payments#

"payments": [ { "type": 1, "sum": 2500.00 } ]

There can be multiple payments, and their sum must match total; the service does not set its own limit on the number of payments — the restriction is determined by the cash register itself and the fiscal document format. For an online store accepting card payments on a website, this is always {"type": 1, "sum": <total>}.

6. vats — aggregate rates#

An optional block: a VAT summary for the whole receipt ([{ "type": "vat20", "sum": 416.67 }]). If it is not passed, the cash register computes the taxes from the items itself.

7. Marking#

The marking code is passed in exactly one format field:

"payment_object": 33,
"mark_code": { "gs1m": "MDEwNDYwNzQyODY3OTA5MDIxOU..." },
"mark_quantity": { "numerator": 1, "denominator": 2 }

mark_quantity (a fractional sale of a marked good) is allowed only together with a marking code. In the v4 protocol nomenclature_code — a hex string — is used instead of mark_code.

Important. The marking code is passed to your cash register as is: the service does not verify the code in "Chestny ZNAK" and does not implement the permissive mode. If your goods are subject to the permissive mode, the check must be performed before the receipt is sent — on the side of your accounting system or cash register software.

8. The agent scheme#

When you sell a principal's goods (a marketplace, a payment agent, a commission agent), the item is supplemented with two blocks:

"agent_info": { "type": "commission_agent" },
"supplier_info": { "name": "Supplier LLC", "inn": "7736570901", "phones": ["+79001234567"] }

supplier_info with a valid TIN is mandatory whenever agent_info is set — otherwise the receipt fails validation. For paying agents, the phone numbers of the payment acceptance operator and the details of the transfer operator are additionally filled in inside agent_info.

9. Other receipt fields#

10. The correction receipt#

For *_correction operations the document body is passed in the root correction field, and the grounds — in correction_info:

{
  "timestamp": "04.08.2026 15:00:00",
  "external_id": "corr-10421",
  "correction_info": { "type": "self", "base_date": "03.08.2026", "base_number": "1" },
  "correction": {
    "company": { "sno": "usn_income", "inn": "7736570901", "payment_address": "https://shop.example" },
    "items": [ /* as in an ordinary receipt */ ],
    "payments": [ { "type": 1, "sum": 2500.00 } ],
    "total": 2500.00
  }
}

• correction_info.type: self — on your own initiative, instruction — by order of the tax authority.
• base_date is always mandatory, base_number — mandatory with instruction.
• The client block is not required in a correction.

Which correction receipt the law requires in which case — in the Correction receipt reference and the breakdowns of typical situations next to it.

Next: online store scenarios · errors and diagnostics · API reference.