So you stop losing 30 hours a month to spreadsheet billing.
FulBill exists for one reason: fulfillment operators on Base need a billing layer Base does not have. That's it. The rest is implementation.
Why
So billing 15 clients runs in the background while you onboard the sixteenth.
An operator with 15 clients spends 20–40 hours a month on manual billing. Loses 5–15% of invoice revenue to errors no one sees. Spreadsheets break between client 10 and 15. Each of those numbers is a concrete reason FulBill was built.
an operator loses every month to manual billing
of invoice revenue leaks through missed deliveries, returns, surcharges
clients — the threshold where spreadsheets break for good
What we DON'T do
We do one thing. Well.
It's easier to understand FulBill by what we don't do:
We don't replace Base
Base stays. Orders, shops, couriers, integrations — everything as it was. You connect FulBill with one API key — it runs alongside.
We don't do warehousing
The warehouse is your job. We don't move pallets, pack boxes, or settle couriers on cartons. That's on you.
We don't serve end merchants
We don't compete with shop platforms. End clients still see their orders in Base — just like before.
We don't build a WMS
Logiwa, CartonCloud, Extensiv — those replace Base. We don't. We connect to your existing Base and run next to it.
We do one thing: bill your clients per-client and give them a portal under your brand. The rest is on you — and that's by design.
Where this comes from
We see you from the other side.
Most companies building tools for operators don't know Base first-hand. We started the other way around — from the merchant's side, the one using Base every day. That's why we know where its limits sit.
- 2016
First own business. Worked at a bank with B2B clients — selling loans and leasing. First lessons in how a business owner thinks: where it hurts, why decisions get postponed, what they actually need.
- 2018
Own e-commerce shop with European reach. Small volumes, but the industry on our own skin: products, warehouse, shipping, returns, couriers. No third-party fulfillment — everything in-house.
- 2020
BaseLinker services. Around a hundred shops onboarded, several fulfillments. Main focus: automation and process optimization in companies.
- 2026
FulBill. From real conversations with operators trying to run a dozen-plus clients on Excel. From real needs, not from theory.
We don't run a warehouse. But we know where Base ends for the merchant — we saw it from a hundred shops. And we know where it ends for the fulfillment operator — because we onboarded several of them directly.
What follows
Every FulBill feature comes from something we've seen.
Product decisions don't come from theory. They come from specific situations where an operator or a merchant was losing time, money, or nerves:
What we saw
Merchants want to see live stock, not yesterday's CSV.
What we built
Client portal synced with Base, with per-company data isolation.
What we saw
Storage billed once a month averages reality. Goods come and go every day — you bill too much or too little.
What we built
Day-by-day storage billing on real Base stock. No estimates, no flat rates. Real days × real rate × real stock.
What we saw
Delivery bookings flood the operator — pallet, carton, container, who knows when.
What we built
Booking form with four types and automatic intake fee.
What we saw
Spreadsheets break when every client has a different pricing model.
What we built
Four storage models × three order models × two return models. Each client their own.
What we saw
Tickets by email are unreadable: which client, which product, which order?
What we built
Tickets with context — Base order number one click away.
What we saw
A return physically comes back, but isn't on the invoice.
What we built
We bill returns per client based on Base data — each return with a fee from the price list. Line item in the same month's settlement.
Want to see FulBill on your data?
Thirty minutes online. Your Base, your clients, a real settlement. No marketing pitch, no "contact us for pricing".