It looks like you’re from {country}
Accounting
Jortt is built on the promise that bookkeeping should mostly happen by itself, and for the bookkeeping half it delivers. What it cannot do is know that an order came in on your site twenty minutes ago.
So the one manual step left is the one at the front: somebody creating the invoice that the order should have created.
Jortt is Dutch online accounting software for freelancers and small businesses, with automatic bank reconciliation, VAT returns, invoicing and quotes. Its selling point is how little bookkeeping knowledge it asks of you: it categorises transactions itself and files the VAT return.
It is a good fit for service businesses and small shops, and a bad fit if you need stock management or multi-entity accounting — which it simply does not have. For connections it offers a documented REST API, so a webshop or a site can create invoices and read back their status.
Jortt automates the back half of the process well, which has an odd side effect: the one remaining manual step stands out more, and gets forgotten more.
When the bookkeeping runs itself, nobody is looking at it daily — which is the point. So an order that never became an invoice is not noticed by anyone until a quarterly check, and by then the customer has forgotten they owe you.
What you see instead
The order creates the invoice, so "no invoice" cannot happen quietly. If the creation fails, that failure is an alert with the order number in it.
The customer exists in your site or shop and again in Jortt. When one of them is updated the other is not, and the invoice goes to whichever version Jortt has.
What you see instead
One system owns the contact and Jortt follows it, matched on email or VAT number. One address change, one place.
Jortt reconciles bank transactions well, but a Mollie payout is one lump sum covering forty orders minus fees. That does not reconcile itself against forty invoices, so somebody splits it out.
What you see instead
Each payment is matched to its own invoice as it happens, with the provider fee as its own line, so the payout that arrives later already agrees with the books.
Less than with a heavier package, because Jortt is quick to work in. The cost is concentrated in two places instead: invoices that are simply never made, and payouts that have to be split by hand.
The missed invoice is the expensive one. In a business doing a few hundred orders a month, one forgotten invoice a month at an average order value of €300 is €3,600 a year that was earned and never billed — considerably more than the connection costs.
Jortt users are usually small enough that the site and the bookkeeping are the whole stack, so getting both right in one project is the cheapest route rather than a luxury.
A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.
The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.
WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.
WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.
When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.
Jortt has no stock or order objects, so the flows are invoices, contacts and money — a short list, and a correspondingly short project.
Orders or bookings as sales invoices (into the tool)
Contact, lines, VAT per line, your own ledger accounts, sent or as a concept. With the order number as reference so the two can always be reconciled.
Contacts (both ways)
Matched on email or VAT number, with one side named as the owner of the billing address.
Payment status per invoice (into the tool)
From Mollie, Stripe or another provider, with the fee as its own line so the payout reconciles later without manual splitting.
Invoices into a customer portal (out of the tool)
A logged-in customer seeing and downloading their own invoices, and what is still open.
The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.
Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.
A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.
Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.
Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.
This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.
A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.
Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.
APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.
For Jortt the project is usually at the lower end of the range: the API is straightforward and there is not much system to map. The same volume caution applies as with any small-business package — below about a hundred invoices a month, do the Growth Scan before you commission anything.
A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.
What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.
Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.
Yes, a documented REST API with token authentication, which is enough for invoices, contacts and payment status — the three things a website actually needs.
What it does not have is objects that do not exist in the product: no stock, no sales orders, no warehouses. If your shop needs those, the connection belongs to the shop platform and Jortt only receives the invoice.
Mostly not, and that is a deliberate design choice on our side. The part that talks to your bookkeeping is one module; the part that decides what an invoice should look like, when it should be sent and how a payment is matched is the bigger half and it does not change.
So a migration means rewriting the adapter, not the project. Budget a fraction of the original, not another full build.
Yes, and for the first month we usually recommend it: the invoice is created with everything filled in, and a person presses send. You get the time saving without handing over judgement while you still want to look.
Most clients switch to sending automatically after a few weeks, once they have seen a hundred correct invoices in a row. Some keep concepts for large orders only, which is a sensible middle.
