SnelStart – Gotchas

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.