How to Automate Invoicing and Shipping: One Flow
An invoice, a courier label, and a status change don't have to be three separate tasks in three panels. We show you how to combine them into one automated flow that kicks off the moment an order is paid.
How to automate invoicing and shipping: the short answer
Stop treating the invoice, the courier label, and the status change as three separate tasks in three different panels. Instead, build a single process (a flow) in which one event — a paid order — automatically triggers a chain of actions: issuing an invoice or receipt, generating a label with the courier, saving the tracking number, changing the status in your store and on the marketplace, and notifying the customer. Done by hand, each package means 2-4 minutes of clicking and retyping data. In a single flow, those same steps run in the background in a few seconds.
In this guide I’ll show you what such a flow looks like step by step, where the typical pitfalls are (statuses, KSeF, address data), and how to roll out automation in your own setup — whether you sell on Allegro, in your own WooCommerce store, or across several channels at once. The key principle: the invoice, the label, and the status aren’t three tasks but three stages of a single process that should run on its own.
Why separated invoicing and shipping cost you time and money
A typical, non-automated way of handling a single order looks like this: you log into your store panel, check the payment, switch to your invoicing software, retype the buyer’s details, issue the document, download the PDF, go to the courier’s panel, retype the address again, generate the label, copy the tracking number, go back to the store, paste the tracking, and manually change the status. With 20 orders a day, that’s hours of work and dozens of spots where a typo can slip in.
Every manual retyping of data is a risk of error: a wrong postal code, a swapped apartment number, an invoice for an incomplete amount, a shipment to an old address. Materials from automation-tool vendors report that eliminating manual data retyping can reduce address errors by more than 90% — these are ballpark figures, so treat them as an order of magnitude rather than a guarantee, and verify them against your own data. What matters for you, though, is a simple effect: fewer “it didn’t arrive” returns, fewer invoice corrections, and fewer nervous phone calls from customers.
The second hidden cost is delays. Marketplaces such as Allegro and Amazon rate sellers partly on shipping timeliness. When you do invoicing and labeling in batches “whenever I get a moment,” some packages go out later than they should. Automation shrinks that gap to a minimum, because the “shipped” status and the tracking number appear in the sales channel right after the package is packed.
Anatomy of one flow: from paid order to shipped package
At the heart of automation is a trigger and the sequence of actions that follow it. The trigger is usually the order status changing to “paid” (or “accepted for fulfillment”). From that moment, the system carries out, one by one, what you used to do by hand. Below is the full sequence of a single, well-built flow.
| Step | What happens automatically | What it means for you |
|---|---|---|
| 1. Trigger | The order status changes to “paid” | The flow starts without a click from you |
| 2. Document | An invoice or receipt is created from the order data | Zero retyping, consistent data |
| 3. Delivering the document | The customer gets a PDF/link, a copy goes to the archive | Order in your bookkeeping |
| 4. Label | The system creates a shipment with the chosen courier | Label ready to print |
| 5. Tracking | The tracking number is saved to the order | Number visible in the store and channel |
| 6. Status | Change to “shipped” in the store and on the marketplace | Timeliness visible to the platform |
| 7. Notification | The customer gets an email/SMS with the tracking number | Fewer “where’s my package” questions |
Note that this is one chain, not seven separate tasks. If you do any step by hand, all the rest wait for you — and that’s exactly where delays and errors pile up. The goal is to reach a state where your only physical action is sticking the label on the package and handing it to the courier.
The trigger is the foundation — sort out your statuses first
The most common beginner mistake in automation: building flashy actions on top of the wrong trigger. The result is painful — invoices get issued for orders that haven’t been paid, or labels are created for items with an incomplete address. So before you set anything up, sort out your order statuses and decide which one really means “ready for fulfillment.”
Rule: don’t invoice or ship before payment (except cash on delivery)
For prepaid payments (BLIK, bank transfer, card, marketplace payment systems), the trigger should be payment confirmation, not the order simply being placed. The exception is cash-on-delivery shipping — there the package goes out before payment, so its trigger is simply the order being accepted for fulfillment. Separate the two scenarios from the start so you don’t ship goods to unpaid carts. You’ll find more on sorting out the order process itself in the piece on automating orders in e-commerce.
The second thing to think through is the order: invoice before label or the other way around? In practice it’s safer to issue the document first (then you’re sure the billing data checks out) and only then generate the label. If something is wrong in the invoice data, the flow stops before the shipment is created rather than after it’s dispatched — a correction is easier then.
Automated invoicing in the reality of KSeF 2026
Invoicing in Poland is changing the rules of the game, because the mandatory National e-Invoicing System (KSeF) is coming in. If you’re building automation in 2026, you need to design it for KSeF from the outset so you don’t have to rework the whole process shortly after. Below is a rough timeline — always verify the exact dates and thresholds at the source (ksef.podatki.gov.pl) and with your own accountant, as the details are sometimes fine-tuned.
| From when (approximately) | Who it applies to | Scope of the obligation |
|---|---|---|
| February 1, 2026 | Companies with turnover above PLN 200 million in 2024 (gross) | Issuing invoices in KSeF; receiving invoices — all taxpayers |
| April 1, 2026 | Other businesses (B2B turnover) | Issuing and receiving B2B invoices in KSeF |
| January 1, 2027 | The smallest (invoices up to approx. PLN 450 and up to approx. PLN 10,000/month) | Deferred obligation to issue in KSeF |
An important buffer: throughout 2026, a transitional period is planned with deferred financial penalties for failing to issue an invoice in KSeF or for technical problems. That’s time for a calm rollout and integration testing, not an exemption from the obligation — treat it as a margin for finalizing your automation, not a reason to postpone it. I break this topic down in more detail in the guide KSeF 2026 for e-commerce sellers.
B2C in e-commerce: receipts and invoices for consumers
This is a key distinction for stores, because most online sales are B2C. The KSeF obligation applies primarily to B2B invoices, i.e., between companies. Invoices for consumers (private individuals) as a rule may, but don’t have to go into KSeF — issuing them in the system is voluntary and usually depends on whether the buyer requests it. You’ll share such a document with a consumer outside the system, e.g., as a PDF with a QR code that lets them verify the invoice in KSeF.
The practical takeaway for your flow: invoicing automation has to be able to tell a business buyer from a consumer buyer and apply a different path. This is an accounting and legal nuance, so settle the exact rules for your sales with your accountant and check the official materials — what follows is not a substitute for tax advice. I describe how this looks in marketplace practice in the piece KSeF and selling on Allegro. I’ve also collected the mechanism itself for generating and sending documents in the feature description invoices and KSeF.
Automated courier labels and status updates
The second half of the flow is shipping. Instead of retyping addresses into each carrier’s panel, you integrate with their APIs. In Poland, you most often connect with InPost (ShipX), DPD (WebAPI), DHL (eCommerce), GLS (MyGLS), Orlen Paczka, and Poczta Polska (Elektroniczny Nadawca). The system sends the courier the full set of data — sender, recipient, dimensions, weight, the chosen service and add-ons (e.g., cash on delivery or insurance) — and receives a ready label and tracking number in return.
A well-built shipping automation delivers several concrete benefits:
- Batch generation. You select the packages ready to ship and create all the labels with a single click, instead of clicking each one separately.
- Bulk printing. Labels (and, for a B2B invoice, the document too) print in a single queue on the printer you specify.
- Pickup manifest. The system prepares a list of packages for the courier, so you don’t collect the numbers by hand.
- Automatic tracking. The tracking number is saved to the order right away and travels to the store and the marketplace.
- Statuses via webhooks. The courier reports changes back (dispatched, out for delivery, delivered), and the system updates them without your involvement.
Package data mapping is crucial: weight and dimensions have to come from the product record, otherwise labels will be created with default parameters and drift away from the courier’s price list. If you’re just starting out with automated dispatch, you’ll find a practical example in the piece on automatic InPost labels, and I’ve described the full scope of this feature on the courier labels page.
Status mapping: how to tie the store, marketplace, and courier together
The most underrated part of the whole flow is consistent statuses across systems. A WooCommerce store names the stages differently than Allegro does, and the courier returns yet other messages. Without mapping, the customer sees “in progress” when the package is already at their door, or the marketplace doesn’t record the shipment on time. Below is a simple scheme for how to map the key states.
| Source event | Action in the flow | Status visible to the customer |
|---|---|---|
| Payment confirmed | Issue the document + reserve stock | Paid / in progress |
| Label created | Save the tracking number | Packing |
| Package handed to the courier | Set “shipped” in the store and channel | Shipped + tracking |
| Webhook: delivered | Close the order | Delivered |
| Webhook: return to sender | Flag for return handling | Return in progress |
Once statuses are mapped — once, and properly — the entire customer notification happens on its own and consistently, no matter how many channels you sell in. It’s also the foundation for reporting: you know how many orders got stuck at the “paid” stage and how many actually went out.
Automation in your own store vs. on a marketplace — the differences
Although the flow is ultimately meant to be a single one, the boundary conditions differ between your own store and a marketplace, and it’s worth accounting for that as you build. In your own store (WooCommerce, PrestaShop, Shopify) you have full control over statuses and buyer data, so it’s easier to set up exactly the trigger and document path you need. The payment gateway confirms the payment, and the status changes predictably.
On a marketplace, some of the rules are imposed by the platform. Allegro and Amazon have their own order states, their own requirements for the shipping deadline, and their own way of passing the tracking number. That’s why, with multichannel sales, status mapping stops being an option and becomes a requirement — without it, your sales panel and the platform diverge in what the customer sees. The second nuance is the invoice data: in marketplace sales you more often get B2C orders where the document is optional, interspersed with occasional requests for a business invoice. Your flow has to recognize this automatically instead of forcing a single scheme on all orders.
The practical takeaway: build one flow, but with branches. A shared skeleton (trigger → document → label → status → notification) and a few conditions that handle the differences between channels, payment types (prepayment vs. cash on delivery), and buyer type (business vs. consumer). A model like this scales without multiplying separate processes for each store.
The most common mistakes in invoicing and shipping automation
- Wrong trigger. Invoicing on “placed” rather than “paid” generates documents for abandoned carts.
- No separation of cash on delivery. A single flow for prepayment and cash on delivery ships goods to unpaid orders or blocks the cash-on-delivery ones.
- Incomplete package data. Missing weights and dimensions on products = labels with default parameters and incorrect settlements with the courier.
- Treating B2C like B2B. Automatically sending every invoice to KSeF without distinguishing the buyer is an unnecessary risk — settle the rules with your accountant.
- No exception handling. The flow must have an “error queue” for orders that didn’t go through (wrong address, missing tax ID) instead of quietly skipping them.
- Invoicing and stock kept separate. If you sell across multiple channels, shipping without a link to stock leads to overselling — more on that in the piece on avoiding overselling.
How to roll out one flow in your setup — a 7-step plan
- Map your current process. Write down every action from payment to dispatch and count how long it takes by hand.
- Sort out your statuses. Set one starting status (“paid”) and the mapping between the store, marketplaces, and courier.
- Fill in your product data. Weights, dimensions, VAT rates, and document type — without them, automation produces errors.
- Choose the document path. Decide when an invoice, when a receipt, and how you handle B2C vs. B2B under KSeF (consult your accountant).
- Connect your couriers. Integrate the carriers you actually use and test the labels on trial packages.
- Turn on notifications. Set up an email/SMS with the tracking number triggered by the status changing to “shipped.”
- Test on a small sample. Run the flow on 10-20 orders, check the documents, labels, and statuses, and only then scale.
Combining the invoice, the label, and the status into one process like this is exactly the direction modern multichannel sales-management panels are heading — Nimo included, a panel for Polish sellers that we’re building with these three stages working as a single flow in mind. Whatever tool you choose, the principle stays the same: the fewer manual jumps between panels, the faster and less error-prone the handling.
Frequently asked questions
Can I automate invoicing and shipping while selling across several channels at once?
Yes — and that’s when automation delivers the most. The condition is one panel that gathers orders from Allegro, Amazon, Empik, or your own store and applies the same flow to each of them, along with consistent mapping of statuses and stock levels.
Does every invoice have to go to KSeF from 2026?
The obligation applies primarily to B2B invoices, according to the timeline (including February 1 and April 1, 2026). Invoices for consumers are, as a rule, voluntary in KSeF. This is an accounting matter — confirm the exact rules for your business with your accountant and at ksef.podatki.gov.pl.
What determines whether the flow works without errors?
The quality of the data and the trigger. A correct starting status (“paid”), complete buyer data, and product weights and dimensions are the foundation. Add an “error queue” for orders that didn’t go through so nothing disappears quietly.
Invoice first or label?
It’s safer to do the document first, then the label. If the billing data is incorrect, the flow will stop before the shipment is created rather than after it’s dispatched — a correction is easier then, without canceling the package.
How much does a flow like this really save?
It depends on scale, but handling one package by hand is usually 2-4 minutes of clicking through. With several dozen orders a day, automation recovers hours per week and clearly lowers the number of address errors and late shipments. Concrete numbers are best measured on your own data, before and after rollout.
Read more
Build Nimo with us
Join the waitlist and be among the first to switch to Nimo when early access opens.
A bonus for the first users on the list