# SnelStart — Accounting API: gotchas

> Canonical URL: https://developers.apideck.com/apis/accounting/snelstart/gotchas

## GET /accounting/bills

`line_items`, `sub_total` and `total_tax` are never returned from this list — SnelStart's
list endpoint for bills is a read-only summary view with no line-item detail. `line_items`
IS available from `bills.get` (by id), which reads the underlying "purchase booking"
record instead (the same one `billsAdd`/`billsUpdate` write to). `sub_total` and
`total_tax` are not mapped there either — not because the booking model lacks the data
(it includes a `btw` VAT breakdown, one entry per VAT type), but because this connector
does not currently derive the two unified fields from it; only `total` is exposed.

## POST /accounting/bills

Only `Laag`, `Hoog` and `Overig` are recognized `line_items[].tax_rate.code` values on
write (SnelStart's purchase-side VAT types); any other value — including `Geen` — results
in that line being booked with no VAT allocation, silently, not as an error.

`bill_date` falling in a period your accountant has locked for review or already closed is
rejected — see the `journal-entries` create gotcha, which this connector's bookings share
the same restriction with.

## GET /accounting/bills/{id}

This reads the same underlying "purchase booking" record `bills.create`/`bills.update`
write to — SnelStart's summary view has no per-record read of its own. `line_items` is
available here (unlike on `bills.list`), but `due_date` is always `null` — the booking
model has no due-date field at all — and `status` is always `"authorised"`, since the
booking model has no payment/workflow state this connector can read either. `sub_total`
and `total_tax` are not mapped either — the booking model does include a `btw` VAT
breakdown, but this connector does not currently derive the two unified fields from it, so
only `total` is exposed. `balance` is genuinely unavailable: the booking model has no
open-balance figure at all.

## GET /accounting/invoices

`line_items`, `sub_total` and `total_tax` are never returned by this connector, on any
operation. SnelStart's list/read endpoint for invoices is a read-only summary view with no
line-item detail; the debit/credit lines only exist on the underlying "sales booking"
record, which `invoicesAdd`/`invoicesUpdate` write to — but has no GET endpoint of its own,
and per the platform's write contract the create/update response returns only `id`. There
is no way to retrieve these three fields through this connector once set.

## POST /accounting/invoices

Only `Laag`, `Hoog`, `Overig` and `Verlegd` are recognized `line_items[].tax_rate.code`
values on write (SnelStart's sales-side VAT types); any other value — including `Geen` —
results in that line being booked with no VAT allocation, silently, not as an error.

`invoice_date` falling in a period your accountant has locked for review or already closed
is rejected — see the `journal-entries` create gotcha, which this connector's bookings
share the same restriction with.

## GET /accounting/customers

`addresses[].country` always returns `NL`. SnelStart stores an address's country as a
reference to an internal country record rather than an ISO code, and this connector does
not resolve that reference — consistent with SnelStart being a Netherlands-only accounting
platform.

## POST /accounting/customers

`addresses[].country` is not written. SnelStart requires a country as a reference to an
internal country record rather than an ISO code, and this connector does not resolve that
reference, so the country is left unset on the created record — consistent with SnelStart
being a Netherlands-only accounting platform. `addresses[].street_number` is also not
written separately; SnelStart stores the street name and house number as one combined
field, so `line1` and `street_number` are concatenated into it.

A SnelStart contact can be both a customer and a supplier at once. To add the supplier
role to an existing customer (or vice versa), call `suppliers.update`/`customers.update`
with that contact's id — this connector merges in the new role rather than replacing the
existing one, so both survive. There is no field exposing which role(s) a contact has, so
a dual-tagged contact appears, unremarkably, in both `customers.list` and
`suppliers.list`.

## GET /accounting/suppliers

`addresses[].country` always returns `NL`. SnelStart stores an address's country as a
reference to an internal country record rather than an ISO code, and this connector does
not resolve that reference — consistent with SnelStart being a Netherlands-only accounting
platform.

## POST /accounting/suppliers

`addresses[].country` is not written. SnelStart requires a country as a reference to an
internal country record rather than an ISO code, and this connector does not resolve that
reference, so the country is left unset on the created record — consistent with SnelStart
being a Netherlands-only accounting platform. `addresses[].street_number` is also not
written separately; SnelStart stores the street name and house number as one combined
field, so `line1` and `street_number` are concatenated into it.

A SnelStart contact can be both a customer and a supplier at once. To add the customer
role to an existing supplier (or vice versa), call `customers.update`/`suppliers.update`
with that contact's id — this connector merges in the new role rather than replacing the
existing one, so both survive. There is no field exposing which role(s) a contact has, so
a dual-tagged contact appears, unremarkably, in both `customers.list` and
`suppliers.list`.

## GET /accounting/payments

SnelStart has no dedicated payments resource — a payment is a bank booking
(`bankboekingen`) that reconciles against an existing sales booking (invoice). List/get
filters SnelStart's bank-booking list to entries carrying a sales-booking reconciliation
line, so a bank booking that only posts to a general ledger account, or that reconciles
against a purchase booking (a bill payment) instead, never appears here.

## POST /accounting/payments

SnelStart has no dedicated payments write endpoint — a payment is created as a bank
booking that reconciles against an existing sales booking (invoice). `account.id` must be
a SnelStart bank account id (a Bank-type daybook, from the connector's own bank-accounts
list) — not a ledger-accounts id, despite the field's generic name. Each `allocations[].id`
must be the id of an existing invoice; if `allocations[].amount` is omitted, `total_amount`
is used. There is no partial-reconciliation status: the write either succeeds (`status:
paid`) or the whole request 400s — SnelStart has no `pending`/`draft` equivalent for a bank
booking.

## GET /accounting/company-info

`country` always returns `NL`. SnelStart's company-info endpoint (`/v2/companyInfo`)
exposes no country field at all — consistent with SnelStart being a Netherlands-only
accounting platform.

## GET /accounting/journal-entries

Listing journal entries is not supported. SnelStart's B2B API has no list endpoint for
memoriaalboekingen — only create (POST) and get/update/delete by id are available, so there
is no way to page through existing journal entries.

## POST /accounting/journal-entries

At least two lines are required, and the debit and credit sides must balance to zero —
both are rejected outright rather than silently accepted. A booking date that falls in a
period your accountant has locked for review, or one already checked and closed, is also
rejected; this can make a write that succeeded last month start failing later with no
change on your side. The same booking-date restriction applies to `invoices`, `bills`,
`payments` and `bill-payments`, since they all post through the same underlying booking
model.

## POST /accounting/attachments/{reference_type}/{reference_id}

Files larger than 10 MB are rejected. There is no chunked or resumable upload path to work
around this — split or compress the source file below that size. The filename is also
constrained: an overly long filename, or one containing characters SnelStart does not
accept, is rejected. When in doubt, keep filenames short and limited to letters, digits,
spaces, hyphens and underscores.

## GET /accounting/bank-accounts

Backed by dagboeken (daybooks), filtered to the `Bank`-type ones — SnelStart has no
dedicated bank account resource. A daybook carries only a name and active/inactive status;
`account_number`, `iban`, `bic`, `bank_name`, `balance` and the other account-detail fields
are not available and are always null. `account_type` is hardcoded to `checking`, matching
the "rekening-courant" (current account) daybooks SnelStart administrations use in
practice. There is no filter/sort/pagination support — the underlying endpoint has no
OData support at all — and no create endpoint, so bank accounts can only be listed, not
created via the API.

## GET /accounting/fiscal-periods

SnelStart has no fiscal-year list. Years are generated from the administration's fiscal-year start month: the current fiscal year and the 9 before it, listed newest first. SnelStart exposes no creation date, so years before the administration existed can be listed. If the company ever changed its fiscal year-end, earlier years are reported on the current year-end, not the one in force at the time. Every record has `type: year`; `id` is the year's start date (`YYYY- MM-DD`) and `name` and `fiscal_year` are the year in which it ends. SnelStart does not expose whether a year is closed, so `status` and `locked_through` are null.

## GET /accounting/fiscal-periods/{id}

An id outside the generated 10-year window answers 404.

## GET /accounting/trial-balance

Built from SnelStart's `rapportages/kolommenbalans` report, which needs the `rapportage` scope on the SnelStart connection key: a key without it gets a `401`/`403`. The report runs from the first day of the fiscal year that contains `end_date` (from the company's fiscal year start month) to `end_date`, which defaults to today. Income and expense accounts are year-to-date; whether the balance sheet columns include the opening balance carried into the fiscal year has not been checked against a live administration, and the report is returned as SnelStart answers for that range. Each account's balance sheet and profit and loss columns are netted into one debit or credit, and accounts with a zero balance are left out. `filter[accounting_method]=cash` returns a `400`: SnelStart reports on booking dates. `currency` is null. A report whose debits and credits do not balance returns a `502`. An administration without a fiscal year start month returns a `422`. `account_id` is the ledger account's id and every line has `line_type` `account`. The response shape is taken from Invantive's data model of the SnelStart API, not from SnelStart's own OpenAPI file, and has not been read live.
## GET /accounting/bill-payments

SnelStart has no dedicated bill-payments resource — a bill payment is a bank booking
(`bankboekingen`) that reconciles against an existing purchase booking (bill). List/get
filters SnelStart's bank-booking list to entries carrying a purchase-booking reconciliation
line, so a bank booking that only posts to a general ledger account, or that reconciles
against a sales booking instead (a payment), never appears here.

## POST /accounting/bill-payments

SnelStart has no dedicated bill-payments write endpoint — a bill payment is created as a
bank booking that reconciles against an existing purchase booking (bill). `account.id`
must be a SnelStart bank account id (a Bank-type daybook, from the connector's own
bank-accounts list) — not a ledger-accounts id, despite the field's generic name. Each
`allocations[].id` must be the id of an existing bill; if `allocations[].amount` is
omitted, `total_amount` is used. There is no partial-reconciliation status: the write
either succeeds (`status: paid`) or the whole request 400s — SnelStart has no
`pending`/`draft` equivalent for a bank booking.

## POST /accounting/bank-feed-statements

SnelStart has no structured bank-statement-import API: the statement is encoded into an MT940
("MT940 structured") file and uploaded via `POST /v2/bankafschriftbestanden`. `bank_feed_account_id` must
be a real bank account number/IBAN already registered in the Bankrekeningen (Bank Accounts) window in the
SnelStart UI — accounts cannot be listed or registered via the API (bank-feed-accounts is unsupported for
this reason), so a mistyped or unregistered account cannot be validated in advance.

`end_balance` and `end_balance_credit_or_debit` are computed from `start_balance` plus the transactions
(not taken from the request) so the uploaded file is internally consistent; a caller-supplied end balance
that disagrees with the transaction total is silently overridden in the response.

The upload is synchronous, so `status` only ever comes back as `success` or `rejected` — `pending` is not
reachable. On rejection SnelStart returns a human-readable Dutch explanation (e.g. the account not being
registered yet), but the unified response has no field to carry it — a `rejected` status gives no reason.

There is no read access to previously imported statements: bank-feed-statements list/get is unsupported.

The encoded MT940 file always declares `EUR` as the statement currency; the unified schema has no
currency field to source a different value from, and non-EUR bank accounts are not supported.


[API reference](https://developers.apideck.com/apis/accounting/reference.md) · [Coverage matrix](https://developers.apideck.com/apis/accounting/coverage)