What a shop owner asks before switching systems.

Phase 1 launches in Sweden with local payment integration and country fiscal packs built in. Phase 2 brings the same platform to India with UPI + GST. Both markets share the same codebase. Only the payment and tax layer differs.

grossDule is built for independent retail of every kind: grocery, fashion, electronics, hardware, pharmacy, cosmetics, and specialty stores. Product variants, batches, and category-specific rules are first-class, so the platform fits your catalog instead of the other way around.

grossDule supports standard POS integration via our API layer. For stores without a POS, grossDule provides a lightweight built-in till.

Generic ERPs are built for manufacturing and wholesale. The shelf, the promotion, and the checkout are afterthoughts. grossDule is retail-first: every feature starts from the reality of running a store, not adapted from a factory system.

Yes. grossDule is offline-first. The queue keeps moving through an outage and every sale syncs automatically the moment you are back online. No lost transactions, no manual re-entry.

No consultants and no migration project. There are three steps between signing up and your first self-explaining day-close, usually about nine days. We onboard your catalog, suppliers, and prices with you as part of joining.

For any stock that carries dates, grossDule runs a FEFO queue (first expiry, first out) and flags items for markdown before they turn into shrink, so short-dated stock sells instead of being written off.

Yes. Multi-location is built in, and every store shares one catalog and one ledger, so the counter, the stockroom, and the accounts never disagree across locations. Tell us how many stores you run and we will scope it with you.

Your data stays yours. Catalog, suppliers, sales, and books are exportable at any time, with no lock-in and no exit fee.

grossDule is barcode-native and works with standard barcode scanners and receipt printers. If you do not have a POS today, the built-in till runs on hardware you likely already own.

We do it with you as part of joining. Onboarding your products, suppliers, and prices is part of early access rather than a service you buy separately.

The till is built for someone who has to serve the next customer, so the everyday actions are the fast ones. The back office is where the depth lives.

The daily shelf sweep catches gaps against expected stock the day they appear, so shrinkage surfaces daily rather than at the monthly count.

No. You set the rule once and the till does the math on every cart, online and in store alike.

Yes. Selling by unit, by weight, or by the case is a first-class case rather than a workaround, with the conversion held once so the shelf label, the till, and the stock figure agree.

Trade and account customers keep a balance and a history, and their invoices and credit notes sit on the same ledger as the counter. A notebook by the till is not a receivables system.

There is no supported list, and that is the design. A device is described in a definition file rather than waiting for a driver in a release, and an element a printer does not understand is skipped rather than throwing an error. Unlisted hardware is usually a definition, not a support ticket.

A 2D imager, even if you only scan EAN barcodes today. Packaging QR and payment QR are both 2D, and retail is being asked to read 2D at the point of sale by the end of 2027. A 1D-only scanner is a purchase you will repeat.

No, and this catches people out: the drawer opens on a command sent to the receipt printer over its kick port. Worth checking before you buy a small portable printer, because most of them have no port.

Today, the practical path is a label-printing scale that emits a weight-embedded barcode, which the till reads and prices with no live link at all. A direct serial connection and price-lookup upload are on the roadmap, and we would rather say that than imply it works now.

Your payment processor should be a choice you can change without changing your point of sale, and card settles onto the same ledger as cash and UPI. We do not require you to use a particular reader to accept a card.

Yes. A phone is a valid till, a stock counter, and a receiving device, which matters most on the Saturday when you want a second lane and do not have a second terminal.

Yes. Double-entry, posting sale, cost of goods, tax and tender as journal entries at the moment of the transaction. That is why the day-close can explain itself in a sentence rather than being a report you check against a bank statement later.

Tax treatment and receipt rules are a fiscal pack for the market a store is in, and every receipt is sealed into a hash-chained record for that locale. Opening in a new market is configuration rather than a fork of the product.

On the roadmap, and on a real clock. India requires invoices to reach the government portal inside a fixed window above a turnover threshold, and the European model builds on a common semantic invoice with a standard serialisation. We are building one invoice model with a mapping per market, and we will say when it lands rather than before.

Per location, per month, with the tiers published rather than quoted. Early access is free while we build together. There is no per-module upsell, and promotions and loyalty are part of the product rather than paid add-ons.

No. A share of turnover is a fine business model for a payments company and a poor one for a shop with thin margins, particularly where the dominant payment rail costs the merchant nothing to accept. You pay for the software, not for selling.

During early access, the team building it. The cohort is small deliberately, because the point of an early cohort is that the feedback reaches the people who can act on it.

Only if you want to sell online. Both read this catalog, pricing, and stock, so adding a storefront later is a switch rather than a second system.

Not unless you set it that way deliberately. There is one catalog and one price book behind both.

On the roadmap, and built as one rail rather than one integration per network: order ingest, status callbacks, and a reconciled payout report. Because the catalog is model-agnostic, joining a network is a projection over what already exists rather than a second product database.