Minox – Gotchas

Minox reports what is outstanding today: filter[report_as_of_date] ages today's open bills as of that date and leaves out bills dated after it, but cannot restore bills that have been paid since. Items are aged by due date, and amounts in other currencies are reported per currency. Each item's transaction_id is Minox's own open-item id, not the bill id; transaction_number is the bill number.

Minox reports what is outstanding today: filter[report_as_of_date] ages today's open invoices as of that date and leaves out invoices dated after it, but cannot restore invoices that have been paid since. Items are aged by due date, and amounts in other currencies are reported per currency. Each item's transaction_id is Minox's own open-item id, not the invoice id; transaction_number is the invoice number.

Attachments are supported on journal entries, invoices, bills, credit notes and bill credit notes (reference_type=journal-entry, invoice, bill, credit-note or bill-credit-note), with reference_id the record's id. A record holds at most one document.

Attachments are supported on journal entries, invoices, bills, credit notes and bill credit notes (reference_type=journal-entry, invoice, bill, credit-note or bill-credit-note), with reference_id the record's id; an id of another type, such as an invoice's id with reference_type=journal-entry, answers 404. Each record holds one PDF: uploading replaces the existing document. Deleting an attachment removes the document only; the record stays.

Balances are kept per accounting period: filter[end_date] returns the position at the end of the period that date falls in. With monthly periods (most administrations) the report's end_date is that month's last day. Minox does not expose the dates of other period layouts (quarters, 13 periods), so there the report covers the whole fiscal year: filter[end_date] must be the fiscal year end or left out, and any other date is rejected with a 400. Without it, the report is as of the end of the current period or of the latest fiscal year. A date after the last fiscal year returns that year's closing position. filter[period_count] is not supported.

Accounts are classified by their RGS code (the Dutch reference chart of accounts), as Minox's RGS trial balance assigns it, which includes accounts created through the API. An account without one is placed by its profit/loss/balance group in Minox: in a balance-sheet group it is listed under uncategorized_items; in a profit-and-loss group it counts towards the result of the open fiscal year, shown as an equity item; without a group it is listed under uncategorized_items and counted in neither result. The year result equals the net income of a profit and loss report over the same fiscal year from its first period.

Lists the bill credit notes of every fiscal year in the administration. A Minox bill credit note is a negative booking on a purchase journal; it is returned here with positive amounts and no longer appears in the bills list. status, balance and remaining_credit come from Minox's open items (paid, partially_paid, or authorised while all of it is open; posted with balance and remaining_credit null when Minox has no open item, or when two of Minox's open items match one credit note (same number, date and kind)); allocations are not returned. Sorting is not supported.

Books the credit note on the administration's purchase journal, which updates the payables straight away. Required: number (a whole number of at most 8 digits), supplier.id, date_issued, total_amount and, on every line, ledger_account.id plus either total_amount or quantity and unit_price. Send the credited amounts as positive numbers. A total_amount that does not match the lines is rejected, and a number the same supplier already used in that fiscal year is rejected with 409. Updating is not supported: delete the credit note and create it again.

Minox bookings have no discounts: discount_percentage and discount_amount, on the document or a line, are rejected; send the discounted amounts. A line tax_amount needs a tax_rate.

Bookings are posted on create: status: draft is rejected. currency must be the administration's own currency: Minox needs an exchange rate with any other, which this record has no field for, so another currency is rejected with a 400. currency_rate, document-level tracking_categories and terms are not stored. The booking goes on the administration's purchase journal; when it has more than one, choose it in the connection's purchase journal setting, or the create is rejected with a 400.

Lists the bills of every fiscal year in the administration; filter[billed_since] returns the bills dated on or after that date. status and balance come from Minox's open items: paid when nothing is open (an overpayment shows as a negative balance), partially_paid when part is, authorised when all of it is. Minox keeps no open item for some older bills; those are posted with balance null. The same applies when two of Minox's open items match one document (same number, date and kind). Sorting is not supported: Minox bookings have no created or updated timestamps.

Creates the bill as a booking on the administration's purchase journal, which updates the payables straight away. Required: bill_number (a whole number of at most 8 digits; Minox stores no letters in bill numbers), supplier.id, bill_date and, on every line, ledger_account.id plus either total_amount or quantity and unit_price.

VAT is calculated per line from the tax_rate percentage, rounded to the cent, unless the line sends its own tax_amount; with tax_inclusive: true the line amounts include VAT. A total that does not match the lines is rejected. The total must be positive: book credits as credit notes. due_date defaults to the supplier's payment terms.

A bill_number the same supplier already used in that fiscal year is rejected with 409; the same number on a different supplier is accepted. Updating is not supported: delete the bill and create it again.

Minox bookings have no discounts: discount_percentage and discount_amount, on the document or a line, are rejected; send the discounted amounts. A line tax_amount needs a tax_rate.

Bookings are posted on create: status: draft is rejected. currency must be the administration's own currency: Minox needs an exchange rate with any other, which this record has no field for, so another currency is rejected with a 400. currency_rate, document-level tracking_categories and terms are not stored. The booking goes on the administration's purchase journal; when it has more than one, choose it in the connection's purchase journal setting, or the create is rejected with a 400.

Lists the credit notes of every fiscal year in the administration. A Minox credit note is a negative booking on a sales journal; it is returned here with positive amounts and does not appear in the invoices list. status, balance and remaining_credit come from Minox's open items (paid, partially_paid, or authorised while all of it is open; posted with balance and remaining_credit null when Minox has no open item, or when two of Minox's open items match one credit note (same number, date and kind)); allocations are not returned. Sorting is not supported.

Books the credit note on the administration's sales journal, which updates the receivables straight away. Required: number (a whole number of at most 8 digits), customer.id, date_issued, total_amount and, on every line, ledger_account.id plus either total_amount or quantity and unit_price. Send the credited amounts as positive numbers. A total_amount that does not match the lines is rejected, and a number the same customer already used in that fiscal year (on an invoice or a credit note) is rejected with 409. Updating is not supported: delete the credit note and create it again.

Minox bookings have no discounts: discount_percentage and discount_amount, on the document or a line, are rejected; send the discounted amounts. A line tax_amount needs a tax_rate.

Bookings are posted on create: status: draft is rejected. currency must be the administration's own currency: Minox needs an exchange rate with any other, which this record has no field for, so another currency is rejected with a 400. currency_rate, document-level tracking_categories and terms are not stored. The booking goes on the administration's sales journal; when it has more than one, choose it in the connection's sales journal setting, or the create is rejected with a 400.

Supported filters: company_name, display_name, email and status. Name filters match anywhere in the name, ignoring case. filter[email] returns the customers that have that email address. Sorting is not supported: Minox customers have no created or updated timestamps.

custom_fields are returned but cannot be written: Minox accepts them without storing them, so they are left out of create and update requests. tax_number must be a valid VAT number; Minox rejects an invalid one with a 400. Customers cannot be deleted.

currency must be the administration's own currency; Minox stores a currency together with an exchange rate, which this record has no field for, so any other currency is rejected with a 400. A customer in another currency (set up in Minox) cannot be updated through the API: Minox resets the currency of a customer to the administration's on every update that does not send it, and does not expose the exchange rate to send it back with, so such an update is rejected with a 400. Sending notes empty or null clears them. Minox keeps one free-text contact person per address (often with a title, such as "De heer G. van der Heiden"), which is not split into first_name and last_name; those fields, and individual, are not supported. Minox has three address types: billing and primary are stored as the postal address, shipping as the delivery address and any other type as the street address, which reads back as office. One address of each Minox type is sent: when several map to the same type, billing wins over primary, and otherwise the first one is used.

A customer in a currency other than the administration's (set up in Minox) cannot be updated: Minox resets a customer's currency to the administration's on every update that does not send it, and never returns the exchange rate it would have to be sent back with, so the update is rejected with a 400 rather than silently changing the currency. currency, when sent, must be the administration's own. Only the fields sent are changed: addresses and contacts are left alone unless addresses, company_name, emails, phone_numbers or websites are in the body. Sending notes empty or null clears them.

filter[name] matches anywhere in the item name, ignoring case. Sorting is not supported: Minox items have no created or updated timestamps.

code and category_id are required. code becomes the item id (letters, digits, dot, dash or underscore); a code that is already in use is rejected with a 409 instead of replacing that item. category_id is the item group.

Prices are per single unit. An item Minox prices per a larger quantity (for example per 100) keeps that quantity: a unit price sent on update is stored scaled to it, and the price that is not sent keeps its value.

Prices are per single unit. An item Minox prices per a larger quantity (for example per 100) keeps that quantity: a sales price (unit_price or sales_details.unit_price) or purchase_details.unit_price sent on update is stored scaled to it, and the price that is not sent keeps its value. The item's code cannot be changed; sending a different code is rejected with a 400.

Lists the invoices of every fiscal year in the administration. status and balance come from Minox's open items: paid when nothing is open (an overpayment shows as a negative balance), partially_paid when part is, unpaid when all of it is. Minox keeps no open item for some older invoices; those are posted with balance null. The same applies when two of Minox's open items match one document (same number, date and kind). Sorting is not supported: Minox bookings have no created or updated timestamps.

Creates the invoice as a booking on the administration's sales journal, which updates the receivables straight away. Required: number (a whole number of at most 8 digits; Minox stores no letters in invoice numbers), customer.id, invoice_date and, on every line, ledger_account.id plus either total_amount or quantity and unit_price.

VAT is calculated per line from the tax_rate percentage, rounded to the cent, unless the line sends its own tax_amount; with tax_inclusive: true the line amounts include VAT. A total that does not match the lines is rejected. The total must be positive: book credits as credit notes. due_date defaults to the customer's payment terms.

A number the same customer already used in that fiscal year is rejected with 409; the same number on a different customer is accepted. Updating is not supported: delete the invoice and create it again.

Minox bookings have no discounts: discount_percentage and discount_amount, on the document or a line, are rejected; send the discounted amounts. A line tax_amount needs a tax_rate.

Bookings are posted on create: status: draft is rejected. currency must be the administration's own currency: Minox needs an exchange rate with any other, which this record has no field for, so another currency is rejected with a 400. currency_rate, document-level tracking_categories and terms are not stored. The booking goes on the administration's sales journal; when it has more than one, choose it in the connection's sales journal setting, or the create is rejected with a 400.

Without filters, journal entries of every fiscal year are listed. filter[start_date] and filter[end_date] narrow by posting date, apply to whole entries and may span fiscal years. Sorting is not supported: Minox entries have no created or updated timestamps.

Invoices, bills and credit notes are not listed here; read and delete them through their own resources (their ids answer 404 as journal entries). Each entry has the id returned on create. On bank and cash journals Minox posts one counter line per journal page; each entry carries its own share of it, as a line on the bank's ledger account (and, for lines with VAT, its share of Minox's VAT postings), so the entry balances. Postings made outside the API that only balance as a group (such as an automatic payment run) are returned per journal page, with an id of the form JOURNAL:fiscal_year:page (for example AB:2022:1); these can be read by that id but not deleted. Opening-balance entries are returned as Minox holds them and do not always balance on their own.

journal_symbol is required and must be the code of an existing Minox journal (for example MEMO), and an entry needs at least two lines. currency must be the administration's own currency: Minox needs an exchange rate with any other, which a journal entry has no field for, so another currency is rejected with a 400. On bank and cash journals Minox books line amounts including VAT: amounts sent with a tax_rate and tax_amount are stored as sent (net, plus VAT; a tax_amount of 0 stays 0), a tax_rate without a tax_amount gets the VAT code's percentage and is booked as net plus that VAT, as on invoices, and a line without a tax_rate on such a journal gets the ledger account's default VAT code, which Minox takes out of the amount. A customer line on a sales journal, or a supplier line on a purchase journal, is rejected: that books an invoice or bill, which is created through its own resource. A line with a customer or supplier is posted to that customer or supplier, which Minox books on the matching control account, and its ledger_account is ignored. Other lines post to line_items[].ledger_account. number, when given, must be a whole number of at most 8 digits. The accounting period follows from posted_at. The entry is booked as a whole: if any line is rejected, nothing is booked.

Minox does not store memo or title (a line without a description takes the memo as its description), currency_rate, or any tracking category after the first on a line. VAT codes (tax_rate) can only be used on journals and accounts set up for VAT in Minox; anywhere else the entry is rejected with a 400. pass_through is not supported. Updating an entry is not supported; delete it and create it again.

Accepts the id returned on create, or a journal page id (JOURNAL:fiscal_year:page) from the list. It returns the same lines as the list, including an entry's share of the counter line Minox adds on bank and cash journals. Invoices, bills and credit notes, and postings that only exist inside a journal page entry, answer 404 by their own id.

Only entries identified by the id returned on create can be deleted. Journal page ids (JOURNAL:fiscal_year:page) are rejected with a 400, and an unknown id with a 404.

code is required: 1 to 4 letters or digits, and it becomes the journal id. A code that is already in use, in any letter case, is rejected with a 409 instead of overwriting that journal. Journals cannot be deleted. currency must be the administration's own currency (or, on update, the journal's current one); any other currency is rejected with a 400, since a journal has no field for the exchange rate Minox requires.

The journal's code cannot be changed (it is the journal's id); sending a different code is rejected with a 400. currency must be the administration's own, or the journal's current currency, which is then left unchanged; any other currency is rejected with a 400, since a journal has no field for the exchange rate Minox requires.

classification and type come from the account's RGS code (the Dutch reference chart of accounts). Total accounts (header: true) and accounts Minox has not mapped to an RGS code have neither. The balance sheet and profit and loss reports classify by RGS too, but they follow the side the balance is on: an account that can swing either way, such as a current account with the owner, is classified here as an asset and appears under liabilities in the balance sheet while its balance is a credit. type is accounts_receivable, accounts_payable or bank only where the RGS code names that role; other accounts get the general type of their group, such as current_asset.

The chart is flat: there are no parent accounts, sub-accounts or subsidiaries, and balances are not returned (use the balance sheet and profit and loss reports).

Supported filters: name (matches anywhere in the name, ignoring case), status and classification. They apply to the whole chart, not page by page. Sorting is not supported.

code is required: a number from 0 to 999999, and it becomes the ledger account id. A code that is already in use is rejected with a 409 instead of overwriting that account. Use a code with the same number of digits as the administration's existing accounts: Minox rejects longer codes with a 400 (for example a 6-digit code in an administration with 4-digit account numbers).

tax_rate.id sets the account's default VAT code. classification and type cannot be set: Minox derives them from the account's RGS code, which is assigned in Minox only, so sending either on create is rejected with a 400. On update they are accepted when they equal what the account reads (as in a record sent back) and rejected otherwise. A new account reads without classification or type until Minox maps it to an RGS code (the account read has none), but the balance sheet and profit and loss already classify it by the RGS code Minox assigns in its RGS trial balance.

classification and type are derived from the account's RGS code, which is assigned in Minox only: they are accepted when they equal what the account reads (as in a record read and sent back) and rejected with a 400 otherwise. code cannot be changed (it is the account's id); sending a different one is rejected with a 400. Fields that are not sent keep their current value.

Amounts are kept per accounting period: filter[start_date] and filter[end_date] are widened to the periods they fall in and must fall in the same fiscal year. With monthly periods (most administrations) the report's start_date and end_date are the dates it actually covers. Minox does not expose the dates of other period layouts (quarters, 13 periods), so there the report covers the whole fiscal year: the filters must be the fiscal year's first and last day or left out, and any other range is rejected with a 400. Without filters the report covers the current or latest fiscal year up to the end of the current period. Accounts are classified by their RGS code (the Dutch reference chart of accounts), as Minox's RGS trial balance assigns it, which includes accounts created through the API. An account without one that is in a profit-and-loss group in Minox is listed under uncategorized_accounts and counts towards net income; one without any group is left out (the balance sheet lists it as uncategorized). Over a fiscal year from its first period, net income equals the balance sheet's result for that year.

Supported filters: company_name, display_name and email. Name filters match anywhere in the name, ignoring case. filter[email] returns the suppliers that have that email address. Sorting is not supported: Minox suppliers have no created or updated timestamps.

custom_fields are returned but cannot be written: Minox accepts them without storing them, so they are left out of create and update requests. tax_number must be a valid VAT number; Minox rejects an invalid one with a 400. Suppliers cannot be deleted.

currency must be the administration's own currency; Minox stores a currency together with an exchange rate, which this record has no field for, so any other currency is rejected with a 400. A supplier in another currency (set up in Minox) cannot be updated through the API: Minox resets the currency of a supplier to the administration's on every update that does not send it, and does not expose the exchange rate to send it back with, so such an update is rejected with a 400. Sending notes empty or null clears them. Minox keeps one free-text contact person per address (often with a title, such as "De heer G. van der Heiden"), which is not split into first_name and last_name; those fields, and individual, are not supported. Minox has three address types: billing and primary are stored as the postal address, shipping as the delivery address and any other type as the street address, which reads back as office. One address of each Minox type is sent: when several map to the same type, billing wins over primary, and otherwise the first one is used.

A supplier in a currency other than the administration's (set up in Minox) cannot be updated: Minox resets the currency to the administration's on every update that does not send it, and never returns the exchange rate it would have to be sent back with, so the update is rejected with a 400 rather than silently changing the currency. currency, when sent, must be the administration's own. Only the fields sent are changed: addresses and contacts are left alone unless addresses, company_name, emails, phone_numbers or websites are in the body. Sending notes empty or null clears them.

code is required: a positive whole number, and it becomes the tracking category id. A code that is already in use is rejected with a 409. Tracking categories cannot be deleted.