Your accounting, in plain language

Post an invoice to the ledger, creating its accounting entries.

This is the point of no return: once booked the invoice can no longer be edited, and undoing it means cancelling it, which posts reversing entries, or raising a credit note. Book only once the draft is final.

Void an invoice.

An unbooked draft is simply voided. A booked invoice has reversal entries created for it, so the cancellation lands in the ledger as its own accounting event. Either way the invoice stays in the register marked as cancelled rather than disappearing, and cannot be revived.

Raise a new customer invoice from a set of line items.

The invoice is created as a draft and given a document number: nothing is posted to the ledger and nothing reaches the customer until you bookkeep it with fortnox_bookkeep_invoice and send it with fortnox_send_invoice_email. While it remains a draft it can still be amended with fortnox_update_invoice.

Record a payment received against a customer invoice.

Until it is recorded the invoice stays open, and every ageing and cash-flow figure keeps counting it as owed.

Registering and bookkeeping are separate steps in Fortnox, and bookkeep defaults to false, so the payment is recorded but not posted until you ask. A payment dated inside a locked period is refused before it is sent, with the lock date named. A partial payment leaves the invoice open for the remainder; write off a difference only when you will not collect it.

Raise a credit note against an existing invoice.

The usual way to reverse an invoice the customer has already seen: instead of voiding the original, this creates a separate credit invoice with its own document number that references it, so both documents remain in the register and the audit trail stays intact. Prefer it over fortnox_cancel_invoice for anything already sent.

Full detail for a single invoice, including every line item, the references and the OCR number.

Reach for it after a list result to see what was actually billed, or to check whether an invoice is still a draft, booked, cancelled or paid before acting on it.

Totals for customer invoices over a period: count, revenue, average, and outstanding balance.

Use it when the question is how much we invoiced rather than which invoices we sent; the figures can also be broken down by customer, by month or by status. Invoices are fetched and totalled locally, so leaving the period off walks the entire history.

Above 10,000 invoices the fetch stops early and the totals then go short.

List payments received against customer invoices.

Use it to see whether an invoice has been settled, in full or in part, and to tell payments that have been bookkept from ones still only registered.

Browse customer invoices: who owes what, what is overdue, and what has already been paid.

The starting point for chasing receivables or summarising sales over a period. Status and date filters run server-side; amount filters are applied locally after a page is fetched, so alone they only narrow what came back — pair them with fetch_all to search the whole ledger.

Email the invoice to the customer.

This sends real email to the address held on the customer record. There is no preview, no draft and no way to redirect it elsewhere, and it cannot be recalled once sent, so confirm the invoice is correct and final first. Correcting a sent invoice means raising a credit note.

Amend an invoice that has not been booked yet.

Only unbooked drafts can be updated. Once fortnox_bookkeep_invoice has run the invoice is fixed, and the only ways left to change it are cancelling it or raising a credit note. Supplying rows replaces every existing line rather than adding to them, so send the full set you want the invoice to end up with.

Add a company or person to the customer register.

The entry has to exist before anything can be billed to it, and invoices, orders and sales analysis all key on the customer number rather than the name. This is the opening step of a new billing relationship.

The number is fixed once the record exists; later updates can change the details but never the key. A customer that has since picked up invoices or orders can no longer be deleted, only deactivated.

Which customers are spending more, and which are spending less.

Ranks customers by the change in invoiced revenue between two periods, read from the invoice register rather than the general ledger, so it follows what each customer was billed rather than what was booked.

Customers are matched on customer number across the two periods, so one that bought in only one of them shows zero for the other and lands at the extreme of the ranking. Filtering on a revenue floor keeps those out of the way.

Remove a customer from the register.

This cannot be undone, and it only works while the customer has no invoices or orders attached. Where there is history to keep, mark the record inactive with fortnox_update_customer instead. Mostly useful for clearing up duplicates and entries created by mistake.

The full record for one customer.

Worth pulling before raising an invoice: it shows the payment terms, VAT treatment, currency and billing address the invoice will be issued against, and whether the account is still active.

Look up customers in the register.

The usual first step before billing anything: invoicing, orders and sales analysis all identify a customer by number rather than by name, so start here when you know who the customer is but not their number. Also the quickest way to see which accounts are still active.

Ranks customers by revenue, invoice count, unpaid balance or average invoice size.

Use it for who the biggest customers are and who owes the most. Invoices for the period are fetched and grouped by customer number locally, so the ranking follows invoice dates in the range rather than when payment arrived.

Above 10,000 invoices the fetch stops early and the ranking is then drawn from a partial set.

Change the details of an existing customer.

Only the fields you supply are touched; everything else is left as it stands. Use it for the ordinary drift — a new address, new payment terms, a corrected organisation number — and to retire a customer that already has invoices behind it by marking it inactive, which is the safe alternative to deleting.

The customer number itself cannot be changed.

Approve a supplier invoice for payment.

Marks the invoice as pending payment, the step a purchase invoice passes through before it can be paid. No money moves and no payment is recorded — fortnox_create_supplier_invoice_payment does that.

Add a company to the supplier register.

The entry has to exist before anything owed to them can be recorded, and supplier invoices, payments and the payables ageing report all key on the supplier number rather than the name. This is the opening step of a new purchasing relationship.

The number is fixed once the record exists; later updates can change the details but never the key. A supplier that has since picked up invoices can no longer be deleted, only deactivated.

Record a payment made against a supplier invoice.

Settles a payable. Until it is recorded the invoice stays outstanding, and fortnox_payables_report and the cash-flow forecast keep counting it as due.

Registering and bookkeeping are separate steps in Fortnox, and bookkeep defaults to false, so the payment is recorded but not posted until you ask. A payment dated inside a locked period is refused before it is sent, with the lock date named. A part-payment leaves the invoice outstanding for the remainder; write off a difference only when it will never be paid.

Remove a supplier from the register.

This cannot be undone, and it only works while the supplier has no invoices attached. Where there is history to keep, mark the record inactive with fortnox_update_supplier instead. Mostly useful for clearing up duplicates and entries created by mistake.

The full record for one supplier.

Worth pulling before registering or settling a supplier invoice: it shows the bankgiro, plusgiro and bank account the money should go to, along with the payment terms, currency and whether the account is still active.

Full detail for one supplier invoice, including its accounting rows.

The list view gives dates, totals and status; this adds the line items with the account each was coded to, project and cost centre, the OCR reference and any comments. Lookup is by the given number Fortnox assigned, not the invoice number printed by the supplier.

List payments made against supplier invoices.

Shows what has been paid out and which of those payments have been bookkept.

Fortnox has no invoice filter on this endpoint, unlike the customer-side one, so narrowing to a single supplier invoice means fetching and filtering.

Browse supplier invoices (accounts payable) by status, supplier, invoice date, due date or amount.

Use it to look up individual purchase invoices: what a supplier billed and what is still open. For outstanding balances as a whole, fortnox_payables_report gives the ageing view.

Amount filtering happens after results come back, so on a single page it narrows only that page; pair it with fetch_all to cover everything.

Look up suppliers in the register.

The usual first step before working with payables: supplier invoices, supplier payments and the payables ageing report all identify a supplier by number rather than by name, so start here when you know who you are paying but not their number. Also the quickest way to see which accounts are still active.

Accounts payable ageing: every unpaid supplier invoice, bucketed by how long it has been overdue.

The report for what we owe, which suppliers have waited longest and what is not yet due, grouped by supplier, by age bucket or both. Invoices not yet due are counted too, so the totals are the whole payables ledger, not the arrears alone.

An invoice with no due date recorded is treated as not yet due, which can flatter the ageing profile.

Change the details of an existing supplier.

Only the fields you supply are touched; everything else is left as it stands. Use it for the ordinary drift — a new address, new payment terms, a changed bankgiro — and to retire a supplier that already has invoices behind it by marking it inactive, which is the safe alternative to deleting.

The supplier number itself cannot be changed.

The balance sheet as at a date, in the statutory Swedish layout.

Follows årsredovisningslagen bilaga 1: anläggningstillgångar and omsättningstillgångar against eget kapital, avsättningar and skulder. Built from the general ledger, so it is what is actually booked.

Fortnox leaves account 2099 empty until the books are closed, so the year's result is computed from the profit-and-loss accounts and shown as its own equity line; without it a mid-year balance sheet does not balance. Any difference between the two sides is reported rather than hidden.

The income statement for a period, in the statutory Swedish layout.

Kostnadsslagsindelad, following årsredovisningslagen bilaga 2: nettoomsättning down through rörelseresultat and resultat efter finansiella poster to årets resultat. Built from the general ledger, so it agrees with the books rather than with invoice totals.

Costs are shown as negative figures, so every line adds to the one below -- the Swedish convention. Revenue is positive.

Opening balance, debit, credit and closing balance for every account.

The report you reconcile the balance sheet and income statement against, and the one an accountant usually asks for first.

Balances are debit-positive: an asset or cost shows positive, a liability or revenue negative. Opening balances come from the financial year's brought-forward figures plus any postings between the year's start and the period's.

Accounts receivable ageing: every unpaid customer invoice, bucketed by how long it has been overdue.

The report for what is overdue, how much each customer owes and how the receivables are ageing, grouped by customer, by age bucket or both. Invoices not yet due are counted too, so the totals are the whole receivables ledger, not the arrears alone.

An invoice with no due date recorded is treated as not yet due, which can flatter the ageing profile.

The VAT return for a period, mapped to Skatteverket's momsdeklaration boxes.

Built from the general ledger, grouped into the numbered boxes on the form, with the amount to pay or reclaim in box 49. Read it before filing: the boxes differ in reliability, and the report marks which is which.

The VAT boxes (10-12, 30-32, 48, 60-62) come from the 2600-2699 accounts, which exist for nothing else. These determine what you pay and are dependable. The taxable-base boxes (05-08, 20-24, 35-42, 50) come from revenue and purchase accounts, which companies customise; if your sales do not follow the standard BAS accounts these will be incomplete even when the VAT boxes are right.

Any VAT account carrying a balance that no box claims is listed explicitly, because an omitted one means the figure is understated. Account 2648, dormant input VAT, is excluded from box 48 on purpose and reported separately.

This is a working figure to check, not a filed return.

Every voucher transaction affecting an account or account range, newest first, with debit, credit and net change per account.

Reads the whole general ledger for the period from the SIE export — one request per financial year, not one per voucher — so the answer is complete however wide the range. No Fortnox financial year id is needed: the years come from the dates, and given none it reads the most recent one, unlike fortnox_list_vouchers and fortnox_get_voucher which genuinely do need that id.

Add an account to the chart of accounts.

Needed when a posting has nowhere sensible to go: a new cost type, a new bank account, a new VAT rate. Nothing can be booked to an account that does not exist, so this comes before the voucher that uses it.

Balance sheet and income statement reports group accounts by BAS range rather than by name, so a number chosen inside the right class lands on the right report line with no further configuration, and one chosen outside every range shows up as unmapped.

Post a manual accounting entry into a voucher series, straight into the books.

The entry must balance: total debit has to equal total credit, and an unbalanced one is refused here before it reaches Fortnox. The transaction date is also checked against the locked period first, because Fortnox answers a posting into a closed month with a generic bad request that names neither the period nor the lock, which reads as a malformed call rather than a closed month.

Use fortnox_list_voucher_series if you are not sure which series takes manual entries.

Remove an account from the chart of accounts permanently. This cannot be undone, and the account must not have any transactions against it.

Deleting is therefore only ever an option for an account created in error. To retire one that has been posted to, mark it inactive with fortnox_update_account instead.

Everything held about a single account: how it is set up for VAT and tax reporting, whether cost centre and project tagging is permitted on it, and its opening and closing balance.

The chart of accounts is what every voucher row keys on, so this is the check to run before posting to an account you have not used before, or when a report line looks like it is picking up the wrong account.

The date the books are locked through, if any.

Nothing may be posted on or before this date. Worth checking before a batch of vouchers or payments, and worth knowing when a write is refused.

The write tools check this themselves, so a posting into a closed period is refused with the lock date named rather than failing as a generic bad request.

One voucher in full: every debit and credit row, with the account, cost centre and project each row was posted to.

A voucher is addressed by its series and number within a financial year, and that year is a Fortnox sequential id (1, 2, 3...), not a calendar year. Call fortnox_list_financial_years first to get the id for the year the voucher was booked in. This is a real difference from fortnox_account_activity and fortnox_search_vouchers, which need no id because they resolve the years from the dates.

Browse the chart of accounts.

Every voucher row and every ledger report keys on an account number, so this is how you find the number to post to, confirm an account exists before writing a voucher, or spot the ones that have been made inactive. Swedish charts follow BAS, where the leading digit sets the class: 1 assets, 2 equity and liabilities, 3 revenue, 4-7 costs, 8 financial items.

The voucher series set up for this company, and which of them accept manual entries.

Series categorise vouchers — commonly 'A' for manual entries, 'B' for bank — but they are configured per company, so read this before fortnox_create_voucher rather than assuming a letter exists.

List vouchers (accounting entries) with their series, number, date and heading — the voucher register, not the postings inside them.

The financial year here is a Fortnox sequential id (1, 2, 3...), not a calendar year, so call fortnox_list_financial_years first to find the id for the year you mean; passing 2025 will not get you 2025. The ledger-reading tools are genuinely different in this respect: fortnox_account_activity and fortnox_search_vouchers need no id, because they work the years out from the dates.

Find vouchers whose own description, or any of their row descriptions, contains a piece of text.

Reads the whole general ledger for the period from the SIE export, so every voucher in the period is searched, not a capped sample. Row descriptions are always matched; asking for the rows changes only what is shown, not what is searched. Given no dates it searches the most recent financial year, and it never needs a Fortnox financial year id the way fortnox_list_vouchers and fortnox_get_voucher do.

Change how an existing account is set up.

Mostly used to rename an account so reports read sensibly, to correct its VAT or tax reporting codes, or to mark it inactive rather than deleting it, which retires the account while its history stays intact. Only the fields supplied are touched; the rest of the account is left as it is.

Sales offers (quotes) with their customer, offer and expiry dates, total and status.

The first stage of the sales pipeline — offer, then order, then invoice — so this is what has been quoted but not yet won. Status is derived rather than stored: cancelled, then converted once the offer carries an order reference, then sent, otherwise draft. fortnox_sales_funnel gives the conversion rates across the three stages.

Expiry is worked out here by comparing the expiry date with today, so an offer can come back marked expired while its status is still sent or draft.

Sales orders with their customer, order and delivery dates, total and status.

The middle stage of the sales pipeline — offer, then order, then invoice — so this is the backlog that has been agreed but not yet billed. Status is derived rather than stored: cancelled, then invoiced once the order carries an invoice reference, then sent, otherwise draft. fortnox_order_pipeline aggregates the same records if you want totals rather than the list.

Order backlog: what has been ordered but not yet invoiced.

Reads the order register for the period, not the general ledger, and splits orders into pending, invoiced and cancelled. The pending value is the work committed to but not yet billed, which is the number most people mean by backlog or pipeline.

An order counts as invoiced purely because it carries an invoice reference; nothing here checks whether that invoice was ever paid.

Costs per cost centre or department, from the general ledger.

Reads voucher rows carrying a cost centre code, sums the cost accounts for each one and shows which accounts drive the largest centre's total.

Only postings tagged with a cost centre are counted, so untagged costs are invisible here and the total will not reconcile to the income statement. The ledger comes from the SIE export, a whole financial year in one request, so the postings themselves are complete for any range.

Create a project in the project register.

Once it exists, its number can be put on invoice rows and voucher rows, which is what makes fortnox_project_profitability able to report on it. Only postings tagged with a project are counted there, so the project has to exist before the work is booked, not after.

Retrieve one article in full.

Worth a call when you need the price and VAT rate behind an article number, or the sales and purchase accounts a line for it will post to. For stocked goods it also separates what is physically on hand from what is reserved and what is actually available to sell; a service carries no stock figures at all.

Retrieve one cost centre in full.

Resolves a code seen on a voucher row or in fortnox_cost_center_analysis to the department it stands for, and says whether it is still in use.

Retrieve one project in full.

The detail behind a project number seen on a voucher row or in a fortnox_project_profitability ranking: what it is called, who is running it, and whether it is still open.

List articles (products and services) from the article register.

Reach for it to find an article number and its current sales price before putting a line on an invoice, or to put names to the article numbers fortnox_product_performance ranks by revenue.

Searching and the active filter are applied by Fortnox rather than after fetching, so they narrow the request itself. Stock quantities only mean anything for stocked goods; services show no quantity rather than zero.

List cost centres (kostnadsställen).

These are the codes fortnox_cost_center_analysis reports against, and the codes that go on voucher rows to attribute a cost to a department. List them first when you need to know which departments the books are split by, or what a code on a posting stands for.

List projects from the project register.

Reach for it to see which projects exist and which are still running, or to put names to the project numbers that fortnox_project_profitability reports on.

Fortnox has no server-side status filter, so status is applied after fetching. Combine it with fetch_all to filter the whole register rather than one page.

Revenue, cost and margin per project, from the general ledger.

Reads voucher rows carrying a project code and nets revenue accounts (3xxx) against cost accounts (4xxx-8xxx) for each project, joined to the project register for names, status and dates.

Only postings tagged with a project are counted, so untagged work never appears and the totals stay below the income statement. The ledger comes from the SIE export, a whole financial year in one request, so the postings themselves are complete for any range.

Update a project. Only the fields you pass are changed.

Mostly used to walk a project through its lifecycle — ongoing when the work starts, completed when it ends — so that the register stays an honest answer to which projects are live. It edits the register entry only; the project numbers already sitting on invoice and voucher rows are untouched, and those are what profitability reporting follows.

Expected cash in and out over the coming weeks or months.

Built from open receivables and payables -- unpaid customer and supplier invoices, bucketed by their due dates -- rather than from the general ledger. Only money already invoiced appears, so salaries, tax and anything not yet billed are absent.

No bank balance is read, so the running balance is relative to whatever opening figure you supply. Overdue items, when included, land in the first bucket, and if the app cannot read supplier invoices the outflows come back as zero with a warning.

Break down actual expenses from the general ledger.

Reads voucher rows for the period and sums them by account or by account class, so the figures are real postings rather than invoice totals, and where the money actually went rather than what was billed.

The ledger comes from the SIE export, which returns a whole financial year in one request, so the breakdown is complete however wide the range. If that export fails there is no slower fallback: the call errors rather than returning capped figures that look complete.

Gross margin over time, from the general ledger.

Sums revenue accounts against cost-of-goods accounts per month or quarter and reports the margin and margin percent for each, plus the movement in margin percent between the first and last bucket.

A bucket with no revenue reports no margin percent rather than dividing by zero, so gaps in the trend are real gaps. The ledger comes from the SIE export, a whole financial year in one request, so every posting in the range is included.

Revenue and invoicing for one period set against another.

Compares invoiced revenue, invoice count, average invoice size and the number of customers invoiced, with the change between the two periods. Read from the invoice register rather than the general ledger, so the figures are what was invoiced rather than what was booked and will not tie to the income statement.

The customer metric counts distinct customers invoiced in the period, not customers who were new to the business that period.

Rank articles by revenue, quantity sold or invoice count.

Reads the line items on each invoice in the period and aggregates them by article number, so the figures are per product rather than per customer. Cancelled invoices are excluded. The general ledger cannot answer this -- a voucher row carries no article number -- so invoice lines are the only source.

Each invoice costs one API call, so a wide range is slow and may be truncated; the response says so when it happens. Lines with no article number are grouped under their description.

Conversion from offers to orders to invoices.

Counts and values for each stage, read from the offer, order and invoice registers over the same date window, with the conversion rate between stages and the value still sitting open at each one. Cancelled documents are ignored.

Conversion is inferred from the reference a document carries onward, and every stage is counted within the same window, so an offer accepted after the window closes reads as one that never converted. A short window understates conversion for that reason.

Revenue, invoice count and customer count across the last few years.

Year-on-year trend read from the invoice register, one calendar year at a time -- 1 January to 31 December -- regardless of how the financial year is set up, so a company with a broken financial year will not see figures that match its annual accounts.

The most recent year only runs as far as today, so it is being compared against complete earlier years.

The identity of the company these credentials are bound to: name, organisation number, postal and visiting addresses, and contact details.

The quickest way to confirm whose books you are actually in, which is worth doing before a first write. It is also where the organisation number and registered address come from when something needs to quote them.

The financial years the books are divided into, with the dates each covers and the accounting method in use.

Fortnox identifies a financial year by a sequential ID (1, 2, 3...), never by the calendar year, so the ID for 2025 is almost certainly not 2025. Call this first to map the year you want onto its ID.

Only the tools taking a financial_year argument need that ID: fortnox_list_vouchers and fortnox_get_voucher. Tools that work from dates, including fortnox_account_activity and fortnox_search_vouchers, resolve the year themselves.