Picture a WooCommerce store in Celje selling nursery furniture and baby gear, around fifty orders daily. Invoices are typed into Minimax one by one. Each month the bookkeeper is sent a spreadsheet and posts from it. A kindergarten orders ten changing tables and requests an e-invoice; staff assemble it manually because the store can only produce PDFs. Stripe settles once a week in a single amount, and working out which sales and charges sit inside it takes an afternoon. Returned pushchairs float in the ledger with no link to the original sale. Here is what changes. Each incoming order is classified as business or consumer, the matching document type is selected, the invoice is generated inside your accounting software and the eSLOG 2.0 version is handed to the exchange provider you already pay for. Posting logic comes from your accountant and we encode it. To be clear about our role: Apply does not act as an exchange provider, does not supply fiscal tills and issues no digital certificates. We integrate tools you selected, from a distance.
First we establish which system creates the invoice: the store, the accounting package or the exchange provider. Numbering, layouts and responsibility for errors all follow from that choice.
Accounting: Minimax, Pantheon, Metakocka, Birokrat, SAOP, Vasco, and when required SAP Business One, Microsoft Dynamics 365 Business Central or Odoo. Sales: WooCommerce, PrestaShop, Magento, Shopify, plus CRMs like HubSpot and Pipedrive. An official API is our first choice; failing that, the import format the package accepts.
eSLOG 2.0
The XML is produced by your accounting package or by our connector, then delivered by your contracted exchange provider. Its reference and delivery status are stored on the order. Changing provider later affects just that one component.
Classifying the buyer
A VAT identification number entered at checkout is validated, and the company receives either an e-invoice or a conventional one, according to what it can accept. Consumers are asked only for the details an invoice legally needs.
Rates and product codes
Tax rate, unit and SKU originate in the accounting item list; the store holds no duplicate. Delivery charges, gift wrapping and discount codes are shown however your accountant prefers, either on their own line or deducted from the price.
Customer records and receivables
Will individuals be grouped under a single “consumers” record or each receive one? Firms and resellers always get individual records so due dates and outstanding balances remain correct.
Payout reconciliation
Settlements from Stripe, PayPal, Bankart or Monri are decomposed into sales, refunds and commission. Money collected by couriers for cash-on-delivery parcels is allocated to orders likewise.
Reversals and fiscal verification
Issued invoices stay untouched. Your accountant determines when to issue a credit note, how partial refunds are posted and which invoices require fiscal verification; we implement those decisions while preserving the link from document to order.
How the work runs
Cloud Minimax or Metakocka is typically quicker to integrate than a Pantheon installation on a company server handling multiple warehouses. A concrete schedule follows our first conversation.
01
Session with your accountant
Accounts, tax rates, customer records, refund and reversal rules, EU cross-border sales. Decisions are theirs; we write them up.
02
Sandbox build
Development uses a test company in the accounting package and a test login with the exchange provider. Your real ledgers stay untouched throughout.
03
Replaying a closed month
A finished month of orders is processed in full, and the output is checked entry against entry with what your accountant booked by hand.
04
Switching on
We launch on the first days of a month, clear of VAT filing dates. Once that month closes, accountant and integration are reconciled together.
Decide which system numbers your invoices. Two systems both issuing numbers lead to skipped sequences, duplicates and blanks no auditor enjoys. One system should assign, the other should only read. Our usual advice is that the accounting package owns numbering and the store simply shows it. Agree this with your accountant before development begins.
Your questions answered
No. We are not an exchange provider, we issue no qualified certificates and we sell no fiscal tills. Your contract is directly with the exchange provider; our job is plugging your store and accounting software into its interfaces. Still choosing? We can compare candidates on technical grounds, above all API documentation and sandbox availability.
Mandatory e-invoice exchange between businesses has been announced. Confirm scope and timing with your accountant and official sources, as particulars may shift. A connection already capable of eSLOG 2.0 output means the change will not trigger another project.
Initially, yes, since posting rules are theirs to set. Most welcome it: month-end becomes checking rather than retyping. Formats and sample files go straight to your bookkeeping firm.
Logic for orders, tax, payments and refunds is held independently of the destination software. Only the export end is rebuilt. Migrating historical periods is your accountant's call.
With a reliable existing plugin it is mainly setup and testing. Payout reconciliation or unusual refund handling adds work. Following our first call you get either an hourly estimate at €50 per hour plus VAT or, where scope is settled, a fixed quote.
Which store platform, which accounting package, any e-invoice exchange provider yet, which payment methods and roughly how many monthly orders? Expect a plan and a timescale in reply.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.
We set essential cookies only: the ones that keep the site running and recall which town you chose. Nothing for ads and nothing that follows you around the web. Details are in our privacy and data protection notice.