e-Boekhouden.nl – Gotchas

filter[period_count], filter[period_length] and filter[report_as_of_date] are not exposed as request filters on this connector, so any request that sets them is rejected (400, unsupported filter) before it reaches this report — the report always returns 4 periods of 30 days each, as of today.

Aging is bucketed by transaction date, since e-Boekhouden's outstanding-invoice rows carry no separate due date.

filter[period_count], filter[period_length] and filter[report_as_of_date] are not exposed as request filters on this connector, so any request that sets them is rejected (400, unsupported filter) before it reaches this report — the report always returns 4 periods of 30 days each, as of today.

Aging is bucketed by transaction date, since e-Boekhouden's outstanding-invoice rows carry no separate due date.

allocations[].id must be the bill's own bill number (the human-readable string), not its internal id.

allocations[].amount must add up to total_amount when both are supplied — e-Boekhouden books each allocation at face value and reports only the new record's id back, so a mismatch would otherwise post the allocated sum and silently drop the difference. A bill payment whose allocations disagree with its total is rejected before it is sent.

The list returns a summary view of each bill: line_items, total_tax, notes, supplier and due_date are only available from bills.get by id, not from this list. total and sub_total are taken from the bill's single summary amount.

Every line item is sent as a line of the bill; the payable-account side of the entry is resolved automatically rather than taken from line_items — it uses the supplier's own configured payable account when the supplier has one set, and the administration's single payable account otherwise. Each line needs a VAT code; a line with no tax rate is sent with the "no VAT" code.

line_items[].tax_rate.code must be one of e-Boekhouden's own VAT code strings (there is no tax-rates resource/endpoint to look these up — see the tax-rates gotcha on this connector). Supplying tax_rate.rate or tax_rate.id instead of .code is not recognized and the line silently falls back to the "no VAT" code rather than being rejected.

A line's own description is not preserved — e-Boekhouden always returns the bill's own top-level notes for every line, regardless of what was sent for that specific line.

customers and suppliers both list the same underlying set of relations. e-Boekhouden does not store a customer/supplier flag on a relation record — a relation only becomes one or the other through how it is later referenced on an invoice or a bill, not through any field on the relation itself. There is no server-side filter this connector can apply to separate the two, so both resources return every relation, and a record created through either resource shows up in both. If you need to tell them apart, classify client-side from your own business context — note that invoice/bill history only works for relations that already have transactions, so a newly created customer or a supplier with no bills yet cannot be classified that way.

source_type: payment covers both payments received and payments sent, since the unified value has no separate bill-payment variant. source_id can be fetched through the resource that matches its direction: payments for a payment received, bill-payments for one sent. Fetching it through the other resource returns 404 rather than a record with the direction flipped — the same applies to every record shared with bills, invoices and journal-entries.

This connector maps invoices to e-Boekhouden's Mutation booking object rather than its separate, richer /v1/invoice endpoint — a payment can only be matched to an invoice booked this way (see the payments gotcha), so mapping the richer endpoint instead would break payment matching. This means no templates, no PDF generation and no priced-line-item catalog — every line item is sent as a plain amount + description + VAT code.

A line's own description is not preserved — e-Boekhouden always returns the invoice's own top-level memo for every line, regardless of what was sent for that specific line.

line_items[].tax_rate.code must be one of e-Boekhouden's own VAT code strings (there is no tax-rates resource/endpoint to look these up). Supplying tax_rate.rate or tax_rate.id instead of .code is not recognized and the line silently falls back to the "no VAT" code rather than being rejected.

The first line item becomes the entry's own ledger account; every other line item becomes an additional row. There is no separate field for the first line's amount — it is derived from the remaining lines so that the whole entry balances to zero, so line_items must already balance (positive debit amounts, negative credit amounts) before it is sent. Each line beyond the first also needs a VAT code; lines with no tax rate are sent with the "no VAT" code.

A per-line description is not preserved for lines beyond the first — e-Boekhouden always returns the entry's own top-level memo for every line, regardless of what was sent for that specific line. Use the entry-level memo for anything you need to find the entry by; don't rely on distinguishing lines by their own description text.

e-Boekhouden's own account category has no separate value for revenue vs. expense — both share a single "Profit and loss" category, so type and classification return other for every profit & loss account rather than revenue/expense. Balance-sheet, bank, debtor and creditor accounts are still typed normally. VAT-related accounts (input tax, output tax, VAT settlement) are typed other_asset/other_liability where the category unambiguously indicates one or the other, and other where it doesn't.

current_balance is not returned — e-Boekhouden's ledger list has no balance field, and fetching it would require an extra per-account request that is not currently implemented.

e-Boekhouden's chart of accounts is a flat list — there is no parent/child hierarchy and no multi-subsidiary concept, so parent_account, sub_accounts, categories and subsidiaries are always empty. bank_account is also empty — e-Boekhouden's ledger account object carries only a code, a name and a category, none of the bank details (account number, IBAN, etc.) that field requires.

e-Boekhouden's own account category has no separate value for revenue vs. expense — both share a single "Profit and loss" category, so type and classification return other for every profit & loss account rather than revenue/expense. Balance-sheet, bank, debtor and creditor accounts are still typed normally. VAT-related accounts (input tax, output tax, VAT settlement) are typed other_asset/other_liability where the category unambiguously indicates one or the other, and other where it doesn't.

current_balance is not returned — fetching it would require an extra per-account request that is not currently implemented.

e-Boekhouden's chart of accounts is a flat list — there is no parent/child hierarchy and no multi-subsidiary concept, so parent_account, sub_accounts, categories and subsidiaries are always empty. bank_account is also empty — e-Boekhouden's ledger account object carries only a code, a name and a category, none of the bank details (account number, IBAN, etc.) that field requires.

allocations[].id must be the invoice's own invoice number (the human-readable string, e.g. the one shown on the invoice document), not its internal id. e-Boekhouden records invoices through two separate systems that don't share a lookup: a payment can only be matched against an invoice recorded through the booking/journal side, not one created through the standalone invoicing/document side — even when the invoice number is identical on both, the latter fails with "Invoice not found".

allocations[].amount must add up to total_amount when both are supplied — e-Boekhouden books each allocation at face value and reports only the new record's id back, so a mismatch would otherwise post the allocated sum and silently drop the difference. A payment whose allocations disagree with its total is rejected before it is sent.

customers and suppliers both list the same underlying set of relations. e-Boekhouden does not store a customer/supplier flag on a relation record — a relation only becomes one or the other through how it is later referenced on an invoice or a bill, not through any field on the relation itself. There is no server-side filter this connector can apply to separate the two, so both resources return every relation, and a record created through either resource shows up in both. If you need to tell them apart, classify client-side from your own business context — note that invoice/bill history only works for relations that already have transactions, so a newly created customer or a supplier with no bills yet cannot be classified that way.