Verifications

A verification is a booked accounting transaction: a header plus at least two entry lines whose debits and credits balance.

Scopes: accounting:read to read, verifications:write to modify.

Read

GET /user-companies/{company_id}/fiscal-years/{fiscal_year}/verifications
GET /user-companies/{company_id}/fiscal-years/{fiscal_year}/verifications/{verification_id}

Query parameters on the list endpoint:

Parameter	Description
`start_date`	`YYYY-MM-DD`. Note the underscore.
`end_date`	`YYYY-MM-DD`. Note the underscore.
`limit`	Maximum number of verifications.
`offset`	Offset into the result set.

A single verification is also reachable at company level:

GET /user-companies/{company_id}/verifications/{verification_id}

Warning

Listing verifications without a fiscal year — GET /user-companies/{company_id}/verifications — is deprecated. Use the fiscal-year scoped endpoint.

Create

POST /user-companies/{company_id}/verifications

Required fields

Field	Type	Description
`description`	string	Verification description.
`series_code`	string	Verification series code, uppercase alphanumeric, e.g. `"A"`.
`date`	string	`YYYY-MM-DD`. Also determines the fiscal year automatically.
`entries`	array	At least two entry objects. Total debit must equal total credit.

Optional fields

Field	Type	Description
`booked`	bool	Default `false`. If `true`, the verification is booked immediately.
`changed`	bool	Default `false`. Set `true` when modifying an already-booked verification.

Entry object

Field	Type	Description
`account`	string	Account code, 4 characters. Required.
`debit`	number	Debit amount. Provide either `debit` or `credit`.
`credit`	number	Credit amount. Provide either `debit` or `credit`.
`account_name`	string	Optional descriptive name for the account.
`description`	string	Optional transaction text for this line.
`deleted`	bool	Optional. Marks the line as struck, for changed booked verifications.
`added`	bool	Optional. Marks the line as added, for changed booked verifications.

Example

{
  "description": "Office supplies",
  "series_code": "A",
  "date": "2026-03-15",
  "booked": false,
  "entries": [
    { "account": "1930", "debit": 500.00, "account_name": "Bank" },
    { "account": "6110", "credit": 500.00, "account_name": "Office expenses" }
  ]
}

Responses

201 on success, with verification_id, series_code, series_number, result and message. 400 on validation errors, 500 on server errors.

Update

PUT /user-companies/{company_id}/verifications/{verification_id}

Same JSON schema as POST. Modifying a booked verification is restricted; set changed: true and mark individual lines with deleted or added.

Delete

DELETE /user-companies/{company_id}/verifications/{verification_id}

Deletes the verification if allowed — that is, if it is not booked, or if it is the last one in its series.

Practical notes

Balance is enforced. Total debit must equal total credit exactly. Round before you send; do not rely on the server to absorb a fractional difference.

The account must exist in the chart of accounts for the fiscal year the date falls in. Fetch the chart first if you are mapping from an external system. See Accounting.

The series must exist for the company and fiscal year. A series code that is not configured is rejected.

Prefer correcting over editing. Swedish bookkeeping law expects a booked verification to stay as it is, with errors corrected by a new, offsetting verification. Build your integration that way rather than around PUT.

Write limits are tight — 120 write requests per hour per key. An integration that posts one verification per transaction will hit that. Batch on your side.