WooCommerce and Icelandic accounting: a guide

Many Icelandic online stores start in the same place: an order comes in through WooCommerce and someone types it into the accounting system again. That works while orders are few. As they grow, so do the mistakes, the stock shown on the site drifts away from reality and month-end turns into reconciliation.

An integration between the store and the accounting system fixes this, but only if it’s properly thought through. This article covers what the integration should do, how three widely used Icelandic accounting systems take in data, and what to weigh up before you choose an approach.

What should the integration do?

A good integration starts by deciding which system owns which data. The most common split looks like this:

• Orders to invoices. When an order is paid, or reaches a given status, it automatically becomes an invoice in the accounting system.
• Customers. The buyer is created or matched in the accounting system so the invoice lands on the right party.
• Products, prices and stock. The accounting system is often the source of truth for SKUs, prices and inventory, and the store pulls updates from it.
• Payments. The payment that came through the gateway is recorded against the invoice.
• Refunds. A returned item needs a credit note, not just a reversal in the store.

Before any code is written, answer one question: where is a product created and where is its price changed? If the answer is “in both places”, trouble is on its way.

VAT: 24% and 11%

Iceland has two VAT rates: the standard rate is 24% and the reduced rate is 11%. The reduced rate covers food, books, accommodation and a few other categories, as the Icelandic tax authority describes. A store that sells both books and gifts, or food and kitchenware, has two rates in the same basket.

The integration has to carry the right rate for every line, not just a total. A common mistake is defining tax classes in WooCommerce and in the accounting system separately, so they don’t match. Another is rounding: if the store calculates tax on the total and the accounting system per line, the two can differ by a few krónur, which surfaces at reconciliation. Shipping needs its own rate too.

Kennitala and customer records

Icelandic accounting systems identify customers by kennitala, the national ID number used for both people and companies. Businesses buying from you will want the invoice issued to their kennitala, so the WooCommerce checkout has to collect it, validate its format and pass it on.

Individuals buying a single item, on the other hand, may not want to hand over their kennitala. Many stores record those sales against a generic cash-sale customer and set up businesses as named customers. Which approach suits you depends on the business and on what your bookkeeper wants to see. If you do collect kennitala numbers, mind data protection: collect only what you need and say so in your privacy policy.

DK: a capable API you have to apply for

DK offers the dkPlus web service, a JSON/REST interface that connects other systems to the DK database. DK’s web services page lists WooCommerce among the systems that can be connected, and documentation is available in a Swagger description and on the dkPlus test site.

Access isn’t self-service: the credentials for the web service come from DK. We help with that, but build it into your timeline.

At Íslandsvefir we have built DKsync, a WooCommerce plugin that syncs products, stock levels and invoices between your store and DK. It does the job for most online stores. When a business needs something unusual, such as special customer terms, several warehouses or an unusual order flow, we build a custom integration on top of DK’s web service.

If you use the dkPOS till system in a physical shop, we also have a gift card plugin. It lets you create gift cards in dkPOS through DK’s web service.

Regla: set up from inside Regla

Regla takes a different route. There’s no separate WordPress plugin; instead the connection is configured inside Regla. You create keys (a consumer key and secret) for the WooCommerce REST API and enter them in Regla along with the store’s URL. According to Regla’s documentation, the store sends orders to Regla, and products have to be linked so Regla can update them correctly in the store.

The upside is simplicity: fewer moving parts on your web server. The downside is that you’re limited to what Regla offers. If you need more, check what Regla supports before commissioning anything custom.

Payday: an official plugin and an open API

Payday, which Visma acquired in 2023, has an official WooCommerce plugin that turns orders into invoices in Payday. It needs API credentials (Client ID and Client Secret) from Payday. At the time of writing, the plugin page says it requires PHP 8.0 or later and hasn’t been tested with the latest three major WordPress releases. Check the current status before you update.

Payday also publishes API documentation, so a custom integration is possible if the plugin isn’t enough.

Off-the-shelf plugin or custom integration?

We build custom solutions, but the honest answer is that an off-the-shelf plugin is enough for many stores. It’s cheaper up front, someone else maintains it and it’s been tested by many users.

An off-the-shelf plugin fits well when:

• the flow is standard: order, payment, invoice;
• you have relatively few, simple products;
• you can adapt your routine to what the plugin does.

Custom work pays off when:

• you have unusual pricing, volume discounts or customer-specific agreements;
• stock lives in more than one place or more than one system;
• the store also has to talk to a warehouse, a booking system or a point-of-sale system;
• the plugin available for your accounting system doesn’t do what you need.

A middle path is often the most sensible: an off-the-shelf plugin for the basics and a small custom module for what’s missing.

The most common pitfalls

Most integrations work well on launch day. The problems show up later. These are the ones we see most often:

• Duplicate invoices. If the same order is sent twice, say because a request timed out and was retried, a duplicate invoice can appear. The integration has to recognise an order it has already sent.
• Silent failures. WooCommerce can notify other systems through webhooks, but it disables a webhook after more than five consecutive failed deliveries. If nobody is watching, the integration can be down for days before anyone notices. You need monitoring and a clear way to resend.
• Mismatched SKUs. Products are paired by SKU. If someone changes it in one system, the link breaks for that product.
• Variations. Sizes and colours are one SKU in some systems and many in others. Decide up front how they map.
• Partial refunds. A partial refund in WooCommerce has to become the right credit note at the right VAT rate.
• Updates. WordPress, WooCommerce and plugins update constantly. Test the integration after every major update, ideally in a staging environment.

Where to start

Start by describing the process as it is today: where orders come from, who types what, and where mistakes happen. Talk to your bookkeeper about how they want sales and VAT recorded. Then pick the simplest option that meets the need, whether that’s an off-the-shelf plugin or custom work. If you’d like help, read about our WooCommerce integration with DK, Regla and Payday, and see the solution write-up for how a custom integration is put together.

If you’re planning a new store, it helps to know how integrations affect the budget. We cover that in How much does a new website cost?.