Exact Online UK – Gotchas

reference_id is the invoice, bill, or journal entry's own unified id — not Exact's internal Document envelope GUID. The connector resolves between the two internally (Exact's FinancialTransactionEntryID, live-verified to equal the unified id for all three reference types), so no manual lookup or pass-through is needed.

file_url is Exact's own document viewer page (https://start.exactonline.{tld}/docs/SysAttachment.aspx?...), not a direct file download link — it requires an active, logged-in Exact browser session and redirects to a login page for an unauthenticated request (live-verified: a plain GET returns a 302 to the Exact login page, not the file). There is no other download-capable URL on this connector's attachment records.

This list has no server-side total count, so pagination metadata never includes a count.

Same as exact-online-nl.

Same as exact-online-nl.

Same as exact-online-nl.

Exact Online does not track settlement on a purchase entry, so balance, remaining_credit, date_paid and allocations are never returned. tax_inclusive, account, tax_code, subsidiary, location, department, tracking_categories, custom_fields and row_version are likewise not populated. status reflects Exact's entry status: an open entry reads as authorised, a processed one as paid, and a draft as draft. Any other status Exact may return falls back to authorised.

Requires a purchase journal code on the connection setting purchase_journal_code; without it Exact rejects the create. Vault presents that setting under the Bills resource, and the same value applies here. Line item total_amount must be a positive amount of at least one cent — Exact derives the document type from the amount sign and rounds to two decimals, so a zero, negative or sub-cent line would record a bill instead of a credit note and is rejected. Exact refuses a duplicate: a credit note whose supplier, reference, date_issued and total all match an existing one is rejected with Already exists, reported as a 500 rather than a conflict. Retrying a create that already succeeded therefore fails instead of producing a second record — vary reference when a repeat is genuinely intended. line_items[].total_amount is always booked as the amount excluding tax and tax_inclusive is ignored, so tax from the line's tax_rate.code is added on top: a line of 100 with a 21% code produces a credit note whose total_amount is 121. This also applies to a tax code Exact presents as tax-inclusive, so sending a gross amount on such a code overstates the credit note by the tax.

Creating a bill payment records the bank transaction but does not automatically reconcile it with the linked bill — the bill's status will not change to paid until the payment is matched manually in Exact Online. A valid bank journal (Type=12) must be supplied via the bank_journal_code connection setting or pass_through[journal_code] per request; without one the API returns 'Invalid journal'.

Same as exact-online-nl.

Same as exact-online-nl.

Exact Online assigns invoice status automatically (open by default) and ignores the status field on create — invoices are finalized/processed in Exact Online, not via the API. Set VAT via line_items[].tax_rate.code; Exact derives the percentage from the code, so line_items[].tax_rate.rate is ignored on create. shipping_address creates a CRM address record against the customer, but does not attach it to the invoice: the invoice is saved with whatever delivery address the customer already had, so only the first address ever sent for a given customer takes effect. A later, different address is stored on the customer and then ignored by the invoice. Set the delivery address on the customer record when it needs to change.

On read, shipping_address.string returns that address record's identifier rather than a formatted address, and the individual lines are not returned.

Same as exact-online-nl.

Limit parameter for pagination is not supported for this resource.

The list returns the same line_items as the single-record read, so no fetch by id is needed for line-level data.

Exact's journal entry header has no date field, so posted_at is derived from the lines: it is the earliest line_items[].date. Only an entry with no dated line falls back to the first day of its financial period (FinancialYear/FinancialPeriod), which is month precision. created_at is when the entry was created in Exact, not its accounting date.

title is the journal's own description. memo is the first non-empty line_items[].description, or null when no line has one. updated_by/created_by are not populated: Exact's header records when it was created and modified, but not by whom.

Exact does not distinguish a customer account from a supplier account at the line level, so each line's account is returned under both line_items[].supplier and line_items[].customer. To tell which it is, match the id against the suppliers or customers list; an account that is both appears in both.

A validation refusal — an unbalanced entry, an unknown or inactive reference (ledger account, journal, VAT code, currency), or a missing required field — returns 422 with the specific reason named. Any other 500 is a genuine unexpected downstream failure, not a refusal the request itself caused.

VAT on a line is selected by tax_rate.code, not tax_rate.rate — the rate is not sent and has no effect. Omitting the code does not mean "no VAT": Exact substitutes the ledger account's own default VAT code, which changes the line's tax amount and can then reject the whole entry as unbalanced with an error naming the balance mismatch rather than VAT. Always send tax_rate.code explicitly rather than relying on a specific ledger account's default.

line_items[].date maps to Exact's per-line Date (a real field, distinct from the header, which has no date field at all — see the list-operation gotcha above). Historical or backdated bookings should set this per line rather than relying on posted_at. line_items[].source_id maps to Exact's per-line Notes, useful for carrying your own reconciliation identifier since description is typically a human-readable label.

Use code as journal_symbol when creating a journal entry. allow_vat applies to general journals. x-apideck-company-id selects the division. This list has no server-side total count, so pagination metadata never includes a count.

type: bank requires iban — Exact needs a bank account reference to create a bank journal. type: payment_service requires a payment service provider reference that has no equivalent in this unified field set — creating a journal with that type will be rejected by Exact. Use pass_through to supply the required vendor field if you need payment_service, or use sales, sales_credit_note, purchase, purchase_credit_note, cash or general instead. type: other has no Exact equivalent and will be rejected — other is a read-side fallback for values Exact might introduce in the future, not a valid input. clearing_account is the unallocated account a bank journal parks incoming movements in. Bank feed statements posted to a journal without one never reach the reconciliation queue. Exact assigns a default on create; set it explicitly to pin a specific account. Only meaningful on type: bank and type: payment_service.

Creating a payment records the bank transaction but does not automatically reconcile it with the linked invoice — the invoice status will not change to paid until the payment is matched manually in Exact Online. A valid bank journal (Type=12) must be supplied via the bank_journal_code connection setting or pass_through[journal_code] per request; without one the API returns 'Invalid journal'.

Exact does not enforce uniqueness on the supplier name — posting the same display_name/ company_name twice creates two separate suppliers, both with a 201. This connector passes the name through as sent rather than matching on write; the caller owns de-duplication (for example, checking suppliers.list for an existing name, or storing the returned id and reusing it) before creating a supplier that may already exist.

status is derived from Exact's IsBlocked flag (false -> active, true -> inactive). Live-verified against a real division: the raw VATCode object has no Active-equivalent field of its own, only IsBlocked. Exact has no third state, so archived is never returned.