Can One App Run Three Marketplace Stores, Your Stock and Your Books?

Some version of this question gets asked in every Indonesian retail group, most weeks:

Is there an app that can manage three marketplace stores at once, integrated with stock, that also handles finance and the reports? And please include the pricing.

It is a good question, asked precisely. It names the three things that have to be true at the same time — one stock number, several sales channels, books that close — and it asks what it costs, which most vendors will not tell you until they have your phone number.

The answers it gets are usually right. They are also usually incomplete in the same way, and the gap is worth understanding before you buy anything.

The answer people give

Almost every reply lands on the same shape: use a marketplace connector for the channels, and an accounting product for the books, and connect the two. In Indonesia that generally means something like BigSeller, Desty or Jubelio on the channel side, and Accurate Online or Mekari Jurnal on the accounting side.

This is good advice, and for a lot of businesses it is the correct answer. If you sell on three marketplaces and nowhere else, a connector will pull your orders into one screen, keep a single stock figure across the channels, and push sales into your ledger. Two subscriptions, both modest, live in days.

If that describes your business, stop reading and go do that. You do not need a retail operations platform to run three marketplace stores. Anyone who tells you otherwise is selling you their roadmap, not your solution.

The interesting part is what happens next — because the question above says “three marketplace stores”, and almost nobody who asks it actually only has three marketplace stores.

What the stack is really made of

It helps to stop thinking about products and start thinking about three layers, because every option on the market is some combination of them.

Layer 1 — channels. Where orders arrive. Shopee, Tokopedia, Lazada, TikTok Shop, Blibli, your own site. This layer’s job is to pull orders in and push stock levels out, per channel, without you logging into five seller centres.

Layer 2 — operations. What physically happens to goods. Receiving from suppliers, holding stock somewhere, moving it between places, counting it, and knowing at any moment what is where. This is the layer people skip when describing their problem, because in a marketplace-only business it is almost invisible: stock sits in one room and leaves when it sells.

Layer 3 — the ledger. What the transaction means in money. Revenue, cost of goods, discounts, commissions, tax, receivables. This is what your accountant and the tax office care about, and it is the layer where mistakes are expensive and slow to find.

A connector is a layer 1 product that does a thin slice of layer 2. An accounting product is a layer 3 product that does a thin slice of layer 2. The two-tool stack works exactly as long as your layer 2 stays thin.

Where the seams show

Three things reliably strain that arrangement. None of them is a reason to avoid the two-tool stack — they are the things to test before you commit to it.

Sync that produces two of everything

Any integration between two systems has to decide what counts as the same transaction. When a connector pushes an order to your ledger and the marketplace also reports a settlement, and a return arrives against the original order, the ledger can end up holding the transaction more than once.

You will not notice this in week one. You notice it at month end, when the sales report and the bank do not agree and someone has to find out why. Ask any vendor to show you a return, a partial refund and a cancelled order flowing end to end — not a happy-path demo. That one request tells you more than the feature list.

Stock that is right per channel and wrong in total

Connectors are good at keeping channels in step with each other. They are less good at knowing what stock you have, because that is a layer 2 question and they only see the part of your inventory that faces a marketplace.

The moment stock exists somewhere a channel cannot see — a warehouse, a store room, a counter, goods in transit between two of them — the connector’s number and your real number start to drift, and the drift is invisible until you count.

The offline half

This is the one that actually decides the architecture, and it is the one the original question does not mention.

Indonesian retail concentrates offline in ways that marketplace-first software does not model. A consignment counter inside a department store is not a warehouse and it is not a marketplace. The goods are yours until they sell. The partner reports sales on their cadence, not yours. Revenue is split by an agreed margin. Each partner has its own reconciliation format and its own payment terms.

None of that is a stock sync problem. It is an operations problem with an accounting tail, and it lives squarely in layer 2 — which is the layer nobody in the thread is selling.

The question behind the question

So the real question is not “which app”. It is: how thick is your layer 2, and how fast is it thickening?

Three marketplace stores and a room of stock is thin. It stays thin while you grow orders. It stops being thin the moment you add any of these:

• A physical store, or a counter inside someone else’s
• More than one place stock can sit, and therefore transfers between them
• Consignment, where revenue is shared and stock ownership is not obvious
• Anyone who needs to know performance per location, not just per channel
• A finance team re-keying anything that another team already typed once

That last one is the clearest signal, because it is measurable. If someone in your business is retyping data that already exists in another system, you are paying a person to be an integration. It is the most expensive integration you will ever run and the only one that gets slower as you grow.

We wrote about what that costs a business at 34 selling locations: a single month of routine sales took two people the better part of two weeks to enter into the accounting system, transcribing what the operational system already held.

What it costs, and why nobody quotes a number

The question asked for pricing, which was fair, and the replies gave rough figures with a caveat — around three million rupiah for the accounting product, and “depends on the package” for the connector.

That caveat is not evasion. It is the actual answer, because the three layers are priced on three different meters:

Layer	Usually priced by
Channels	Order volume, or a tier that caps it
Operations	Locations, or users, or both
Ledger	Users, plus add-ons for things like per-location reporting

Which means the honest way to compare quotes is not to compare monthly figures. It is to work out what each meter will read in eighteen months — how many orders, how many places stock sits, how many people need access — and price all your options against that. A stack that is cheapest today and meters on a number that is about to triple is not cheap.

One specific trap: some accounting products charge extra for reporting broken down by location. If per-counter or per-store performance is the reason you are buying anything at all, check whether it is included or an add-on before you compare anything else.

For what it is worth, Delos Retail is priced by selling location, per month — a physical store, a consignment counter and an online marketplace channel each count as one. So the bill follows the size of the operation rather than the number of people using it, and training a whole store team costs nothing extra.

Where we actually fit

We should be plain about this, because the honest answer is not “us” for everyone reading.

Delos Retail is a layer 2 product. It is the operations layer — stock across every location and channel, transfers with real states, goods receipt, stock counts, consignment handled as a first-class case rather than a workaround.

It does not replace your accounting product. It posts into it. Every operational document carries a mapping to the chart of accounts, so a sale recorded at a counter becomes a journal entry without anyone retyping it. For the client above, that took corrective journal entries — the ones a wrong-month entry forces someone to write after the fact — from around ten a month to one or two.

Accurate Online is a good product and most Indonesian businesses should be using something like it. The question is never whether you need a ledger. It is what sits between the shop floor and the ledger, and whether that thing is software or a person with a spreadsheet.

How to choose

If you take one thing from this, make it this list. Answer honestly:

1. Where can stock physically sit today? Count the places. Include the store room and goods in transit. If the answer is one, buy a connector and an accounting product and get on with your life.
2. Will that number grow in the next eighteen months? If yes, price every option against the future number, not today’s.
3. Is any part of your revenue consigned? If yes, ask each vendor to show you revenue share calculated per partner and per item. Many will show you a workaround.
4. Does anyone retype data between systems? Cost it. Hours per month, times a salary, times twelve. That is your budget, and it is usually larger than you expect.
5. Do you need performance per location? Ask whether that is included or an add-on, before comparing prices.
6. Ask every vendor to demo a return. Then a partial refund. Then a cancelled order after settlement. The happy path is not where systems fail.

Where to start

You can answer most of this without buying anything.

Take last month. Write down every place a number about your business was typed by a human, and where it came from. Not the systems — the keystrokes. Who entered what, from what source, into which screen.

Most retailers find between three and six such points, and are surprised by at least one of them. Each is a place where two numbers can disagree, and where they will disagree in the month you are busiest.

If that list is short and everything happens in one room, the two-tool stack is your answer, and it is a good one. If the list is long, and it runs through counters and stores and a warehouse and a finance team who all touch the same transaction in turn, then no amount of channel sync will fix it — because the problem was never the channels.

If you want to see what the second case looks like when it is working, book a walkthrough and we will show you against your own locations.