BaseLinker integration: invoices issued for orders automatically
Marketplace orders flow into Księgowskaz and the issued document number returns to BaseLinker. How to set it up and what to verify first.
A seller running accounts on several platforms usually has one system for orders and another for accounting. Manual work sits between them: export, spreadsheet, import, corrections. The Księgowskaz integration with BaseLinker removes that stretch — an order in the right status becomes a sales document on its own.
How the data flows
- BaseLinker collects orders from the connected sales channels and assigns them statuses.
- Księgowskaz pulls the orders in the chosen status together with their line items, buyer details and payment method.
- From the order it creates either an invoice or an entry in the retail sales register — depending on whether the buyer supplied company details.
- The document goes to the e-invoicing system, and the number assigned to it returns to the order in BaseLinker.
- The sale enters your tax records with no extra step on your side.
The whole thing runs on a cycle, so nothing has to be triggered by hand. An order that changes status at eleven in the evening has its document issued before the first coffee of the next day.
If an order does not meet the conditions — buyer details are missing, or a rate has no counterpart in the dictionary — no document is created and the order lands on a review list. That behaviour is deliberate: better to issue a document a day late than to issue it wrongly and correct it afterwards. The list stays short, provided the rate dictionary was mapped properly once.
Setting it up step by step
- In BaseLinker, generate an API access token and limit its permissions to orders.
- In Księgowskaz, add the integration, paste the token and indicate the sales account the documents should go to.
- Choose the order status that means ready to invoice — most often the one assigned once payment has been recorded.
- Map BaseLinker's tax rates onto the rates in Księgowskaz, including the rate for the delivery charge.
- Set a separate numbering series for documents from the integration, so they can be told apart from invoices issued by hand.
- Run a test pass on a dozen or so orders and compare the result with what you would have issued yourself.
Four settings that trip people up most often
- The delivery charge is sometimes a line with a different rate from the goods. If the mapping ignores that, the corrections only surface at month end.
- Buyers type their tax identification number into the notes field or into the company name. It is worth forcing a separate field in the order form.
- Foreign orders: selling to a consumer in another EU country may require settlement under the OSS scheme, so the integration has to know the delivery country, not just the billing address.
- Cash on delivery has a different tax point from prepayment, and the status in BaseLinker changes later than the goods actually leave.
Before you go liveTest the integration on orders covering the full range of cases: business and consumer, domestic and foreign, prepaid and cash on delivery, full and partial returns. One day of testing saves a week of corrections.
Returns and corrections
A return in BaseLinker usually means an order status change and the creation of a goods return. On the accounting side you need a correction linked to the original document. The integration carries that information across, but the decision about the date on which the correction is recognised is yours: a return reported on the last day of the month may fall into the current period or the next one, depending on when it was accepted.
It is good practice to leave one exception for manual handling — partial returns where delivery carries a different rate from the goods. There are few of them, and an automatic split of the amount rarely matches what actually went back to the customer's account.
What it is worth in numbers
A shop issuing five hundred documents a month and spending an average of forty seconds on each loses more than five hours a month on clicking alone. That excludes corrections and the hunt for orders whose document was never created at all. The integration moves that time into reviewing exceptions, of which there are in practice a dozen or so rather than several hundred.
The second gain is less visible but more important: documents are created at the same pace as sales, so the records are complete throughout the month rather than only in the last week before the deadline. When something does not add up, you see it on the day of the transaction, not three weeks later.
Integration is not about clicking faster. It is about not clicking at all.
