Fortnox skillsPublished June 3, 2026
Ready-made Fortnox skills and how to build your own
A practical guide for giving an AI agent better judgement in Fortnox: which skill patterns to start with, how to structure them, and which rules keep them safe in real accounting work.
A visitor recently asked whether there are ready-made Fortnox skills, or how to build good ones. The short answer is yes. The more important point is that a good Fortnox skill is not just a list of API endpoints. It is a workflow with accounting context, error handling, and clear boundaries around writes.
Core idea
Why skills are needed on top of the API
The Fortnox API gives access to data and operations. It does not answer the whole question of how an agent should work. The agent needs to know when to choose customer invoices instead of supplier invoices, how to handle several Fortnox companies, which dates and filters matter, and when to stop instead of guessing.
That is where skills help. A skill captures the practical way to perform a recurring Fortnox job. It does not only say what can be called; it says how the agent should reason and what it should check first.
The Nordsynk model
Skills first, generic API discovery second
In Nordsynk, the agent uses one MCP surface. Inside it, it can search customer-facing Fortnox guidance with skills.grep, load compact metadata with skills.describe, read the full guide with skills.read, and run reviewed skill exports with skills.invoke when a workflow is sensitive or recurring.
For the long tail of the Fortnox API, codemode.grep, codemode.describe, and codemode.request are available. The idea is simple: start with a relevant skill when there is a known workflow, and fall back to API discovery when the task is new or more generic.
Ready-made Fortnox skill areas to start with
These areas show up often in real Fortnox questions, so they are good candidates for reusable skills.
Customer invoices
List, find, and summarize customer invoices. Follow up unpaid or overdue invoices, OCR, status, balance, and payment history.
Supplier invoices
Work with accounts payable, incoming invoices, OCR/interpreted rows, authorization, payment status, and overdue supplier invoices.
Vouchers and bookkeeping
Search vouchers, explain rows, look up accounts, validate debit and credit, and prepare entries without inventing accounts.
Document archive and attachments
Find uploaded files, verify file IDs, attach documents to vouchers, and handle common cases where the right ID is not the one that first looks right.
Reports and exports
Export SIE, prepare result reports, analyze revenue, accounts, and periods. Financial years and exact dates matter extra here.
Payroll
Read payroll runs, payroll periods, employees, and salary rows when Fortnox permissions and product licenses allow it.
The anatomy of a good Fortnox skill
A skill does not need to be long. It needs to be clear where the agent would otherwise make mistakes.
1. Trigger in the user's language
Use triggers customers actually say: unpaid invoices, incoming invoices, approval, SIE, vouchers, result report. API names can be included, but they should not be the only entry point.
2. Company context first
If the user has several Fortnox companies, the skill should tell the agent to select or ask for the right company before reading or writing.
3. Describe schema before uncertain calls
When filters, path parameters, or request bodies are uncertain, the agent should inspect the surface first. This reduces invalid filters, wrong years, and wrong field names.
4. Writes are separate decisions
Create, update, bookkeep, email, approve, and delete are writes. The skill should require a clear summary and explicit confirmation before anything changes in Fortnox.
5. Error handling that stops guessing
A good skill explains what the agent should do for common Fortnox errors. Sometimes the correct behavior is to stop, report the blocker, and ask the customer to fix permissions, matching, or period setup.
Five rules that make Fortnox skills more robust
Keep each skill narrow
A skill for supplier invoices and authorization will be better than a generic skill for the whole finance department. Narrow skills produce clearer triggers and better error handling.
Codify the exceptions
The easy-to-miss details should live in the skill: the right file ID, the right SIE parameter, the right financial year, or that OCR rows are not always finished supplier invoices.
Fetch context once
If many voucher rows need account names, fetch the chart of accounts once and join locally instead of making one request per account.
Be explicit about uncertainty
If Fortnox permissions, product licensing, or period setup makes the answer uncertain, the agent should say so. Accounting work benefits from precision, not confident guesses.
Let reads and writes have different rhythm
Reads can be fast and iterative. Writes should be slower: show target company, operation, important payload, and consequence before the customer approves.
A simple template
This compact structure works for most Fortnox skills.
---
name: fortnox-supplier-invoices
description: Use when the user asks about supplier invoices, incoming invoices, OCR, attest, payment approval, or overdue accounts payable.
---
# Fortnox Supplier Invoices
## Overview
Use this skill for supplier invoice questions and workflows.
## Workflow
1. Resolve the Fortnox company if ambiguous.
2. Search the relevant invoice, OCR, inbox, authorization, or payment surface.
3. Describe the endpoint before uncertain filters or writes.
4. Read with the narrowest useful filters.
5. For writes, summarize the operation and require explicit confirmation.
## Rules
- Do not assume an incoming OCR row already has a supplier invoice number.
- Do not invent suppliers, accounts, dates, or authorizers.
- Stop on deterministic validation or permission errors and report the blocker.
Conclusion
Good Fortnox skills make the agent more accounting-aware, not just more technical. They capture the right language, the right checks, and the right stopping rules. Start with a narrow workflow, write down what an experienced accountant would verify, and let API discovery execute the work - not replace judgement.