Where the “truth” about your data lives
The first question is not “which API” but “which system has the final say”. For each piece of data it should be clear where it is created and where it is only displayed. If you edit a product price both in the e-shop and in the stock software, the integration cannot tell which change counts, and sooner or later it overwrites one of them.
The simplest step is a short table. It does not have to be technical; it only has to be agreed by the owner, the accountant and the person who handles orders.
| Data | Where it is often created | What to ask |
|---|---|---|
| Order | E-shop | Does it go to invoicing right away, or only after payment? |
| Price and VAT | E-shop or stock software | Where is the price changed and who may change it? |
| Stock level | Stock | How often should it show up in the e-shop? |
| Invoice and credit note | Invoicing or accounting | Who issues the document and who may correct it? |
| Customer | E-shop | What happens when a customer changes their billing details? |
If you cannot agree on a row, that is good news: you found out before development, not after launch.
Document numbering, VAT and rounding
Numbering. Decide who assigns the document number. When numbers are created both in the e-shop and in invoicing, you can easily end up with two series, gaps or duplicates. Your accountant will tell you what your numbering requirements are; the integration then just has to follow them.
VAT. Write down which rates you sell at, whether one order can contain goods at different rates and how shipping and payment fees are charged. If you sell abroad or to VAT-registered businesses, that belongs in the brief from the start, not as an exception after launch.
Rounding. The e-shop may calculate VAT per line while invoicing calculates it per document. The difference tends to be a fraction of a crown, but once the invoice amount differs from what was paid, payment matching stops working. Take a few real orders with a discount, shipping and mixed rates and have both systems calculate them. Wherever the numbers drift apart, you need a rule.
Credit notes, returns and payment matching
A smooth order is easy to connect. The time goes into the others: a partial return, an exchange for another size, a cancellation after the invoice went out, a discount added later. For each, answer who enters it, in which system and what should flow back, such as returning items to stock.
- Is a credit note created automatically on a return, or does the accountant issue it by hand?
- Do goods go back into stock straight away, or only after inspection?
- How do you know a payment belongs to a specific order? Payment reference, order number, or something else?
- What happens with overpayments, underpayments and payments with no reference?
- Who deals with a payment that arrives after an order was cancelled?
At Layered we left payment matching where it already worked. After an order, Fakturoid creates a proforma invoice with a QR payment code, Fakturoid matches the incoming payment and notifies the website by webhook. Only then is the final invoice issued and the ticket sent, and the system makes sure it is not issued twice. The website does not match payments itself; it reacts to what invoicing confirms.
An integration will not decide for you what is right. It just does what you agreed on, faster and more accurately.
API access and a test environment
Before anything is promised, you need to find out what the other side allows. Accounting and stock software differ here: some have a public API, others only file exports or a connection through an add-on, and with some the API is part of a higher plan. We check this at the start, not halfway through development.
- Who owns the accounts. Access and keys should sit on company accounts, not on the personal account of a former colleague or supplier.
- Who grants access. Often the accountant or an external administrator. Allow for it to take a few days.
- Permissions. The integration only needs what it actually does. If it only issues invoices, it does not need access to everything.
- Test environment. Find out whether your software offers a test account or sandbox. If not, agree where testing will happen so test invoices do not end up in the live series.
- Test data. Prepare ten to twenty real orders, including the awkward ones: with a discount, a return, a foreign customer.
Who will own the integration and its code belongs in the contract. We agree on access, documentation and the scope of the source code handover in the proposal and contract before work starts.
What happens during an outage and who watches for errors
Every system goes down now and then. Invoicing has maintenance, stock does not respond, a customer mistypes their company ID. The question is not whether it happens but what comes next. An order should neither get lost nor be sent twice.
For each integration we agree on three things. What gets retried automatically and how many times. Where failures are recorded, so you can see what failed and why, not just that something did. And who gets the alert. We set up retries, logging and alerts based on what the connected systems allow; not every piece of software supports all of it.
The last point is the one most often forgotten: a person’s name. An alert that lands in a shared inbox nobody reads is the same as none. Decide who handles errors on your side, who covers during holidays, and what counts as an operational error (a wrong company ID) versus a technical one (the integration is down). The first weeks after launch usually call for adjusting rules rather than code.
A one-page checklist
- For each piece of data we know which system has the final say.
- We know who assigns document numbers, and the accountant has approved it.
- VAT rates, shipping, discounts and foreign sales are written down.
- We ran a few real orders through both systems and the amounts match.
- We know how a return, cancellation, credit note and a payment with no reference are handled.
- API access sits on a company account and we know who will grant it.
- We have a test account or an agreement on where testing happens.
- We have a set of test orders, exceptions included.
- We know what happens during an outage and who gets the alert.
You do not need every answer to get started. It is enough to know where the gaps are and go through them together at the beginning. How we build integrations and what each scope costs is on the Integrations and automation page. A single connection between two systems starts there from CZK 18,000 excluding VAT.
You can get an indicative scope from the calculator. If you would rather go through the checklist against your own e-shop, let’s discuss your project in a 30-minute consultation.
