What Leara solves

Mid-market retailers need the same commerce the large chains buy — without platforms built for fifty stores. Leara sits in the middle of the systems you already run.

A typical picture: the business system has no variants or product groups. The webshop does not know what sits in the store. Stocktaking is paper. Inbound is typed by hand. A web order waits in the central warehouse even though the store has the line.

Leara takes data from the systems you already run, enriches it, and mirrors it back. The office works in the web app. The floor works in the iOS or Android app. Invoices land in the business system. Web orders land via e-commerce. Same stock. Same order book. Same product.

Who it is for

Retail in a broad sense — companies with a store and/or a webshop that need products, stock, and orders under control. A large share of B2B. Sweden first. Not hospitality.

Sweet spot: 1–5 stores plus e-commerce, often from around SEK 5–10 million in turnover, owners who work the floor.
Verticals in practice: building and DIY, forest and garden, pet, sport, interiors, apparel, grocery, wholesale.
Personas: product and order owners on the web; warehouse and store staff in the app. Functions overlap on purpose.

What Leara is not

Leara does not replace the business system. Bookkeeping, invoice numbers, and payment status in the ERP stay there.
Leara does not replace e-commerce. The shop is storefront and checkout.
Leara is not a standalone 3PL WMS, and not a franchise product.
Leara is not SAP, Hogia, Adyen, or Stripe. Those names are not live connectors.

How you start

An account can be created without a sales call. Typical path: connect the business system, load products and stock, set stores, test, then e-commerce and floor apps. Packaging is platform plus warehouse package plus per-store add-ons. Amounts live on the pricing page and can change.

In the middle — not in the chain

Many make the business system the hub, or chain PIM → e-commerce → till → ERP. Fields are then lost in the weakest link. Leara is the rich data model everything mirrors against.

Fortnox, for example, has no variant handling and no article groups. Leara adds its own fields and structure — variants, groups, attributes, images, price including VAT — and sends what the webshop needs. No system in the chain is allowed to limit the rest.

Who holds the record

Bookkeeping, invoice numbers, ERP payment statusLive: The business system. Live: Fortnox.
Operational stockLive: Leara. Reservations, picks, inbound, and stocktaking write against the same mirror.
Product dataLive: Leara. Variants, groups, attributes, brands, suppliers, images.
OrdersLive: Leara aggregates. Channel and location travel with the order. Invoicing goes out to the ERP.

Two surfaces, one operation

The web is the office: registers, orders, quotes, closing a stocktake, purchasing at overview, integrations. The app is the floor: scanning, picking, inbound, stocktaking, purchasing. Same API. Same account. The web is online. The phone can count without coverage.

How the parts connect

One API in the middle (core) owns articles, orders, inventory, customers, quotes, and the connectors out.
Web, iOS, and Android talk to that API. JWT sign-in, account as the tenant key.
A print service pairs local agents with the cloud — labels without opening the firewall.
Leara’s internal admin is a separate service. It is not the customer surface.

What sits in the platform

Modules you can show in a demo. Packages control how much is unlocked. What the code does not support is not promised here.

Orders

One order bookLive: Web orders and orders you create land in the same book. Sales channel and store travel with them. Status from created to picked.
Pick where the goods areLive: An order can be picked in the central warehouse or a store. Partial shipments in the flow. Automatic split when stock is missing is not live — uncovered orders stay visible for manual handling.
Click & collectIn code: Web orders reserve stock. Pick lists sit with the warehouse. No separate order book. Leara does not replace the till at pickup.
Multi-pickLive: Up to seven orders in one pick run, then a notice for pickup or a freight booking.
ReturnsIn code: Returns in the order flow. Store return exists in code. Cross-channel return against an e-commerce payment is a vision, not a finished till return.

Inventory

Stock and reservationLive: Operational stock per warehouse and store. Orders reserve. The next sale is against what Leara shows — not against three registers.
StocktakingLive: Full-year or partial. The web starts and closes. The app counts, with camera or hardware scanner. Live between devices. Counts without coverage are written to disk before the network. Close waits until counting devices have drained. A document can go to Fortnox.
InboundLive: Receipt against a purchase order or standalone. You count. Stock moves when you accept.
Smart inboundLive: Upload a delivery note, invoice, or packing list as PDF or photo. Leara reads and matches against the register. Unmatched lines surface for review. The model never finishes the receipt and never moves stock on its own.
PurchasingLive: Suggestions from reorder points or orders. Purchase orders to the supplier.
TransfersLive: Moves between locations, on web and in the app.
Outbound and RMAIn code: Present as warehouse functions in the Pro package. Depth in a demo — not as a separate product name here.

Product data, price, customer

CatalogueLive: Articles, variants, groups, attributes, brands, suppliers, image bank. What the business system often lacks. What e-commerce is fed.
Price files and campaignsIn code: Price-file import. A campaign engine in code: campaign price, tiers, mix and match, discount codes, margin checks. How it is sold as a module varies by plan.
CustomersLive: Customer register and groups, synced with the ERP. Advanced B2B (relations, credit per reference) is packaged — depth is shown in a demo.
Quote ProLive: Digital quotes with templates. The customer can adjust and sign. Accept creates an order. Public link, no login required for the recipient.

Invoicing and statistics

Invoice against the business systemLive: An order can become a Fortnox invoice. Leara does not keep the books. Payment status lives in the ERP.
StatisticsLive: A dashboard and sales overview in the web app. Not a BI tool. Not a forecasting engine.
LoyaltyNot in catalogue: Appears as a menu item and in internal admin. Not sold as a product here.

What is connected

This guide names systems because it is technical. The homepage does not make Fortnox or Shopify the brand. Live means an adapter in the platform. Planned means a price list or roadmap without a production connector.

Do not trust the in-app catalogue as truth. It mixes dummy status for systems with no adapter. The tables below are verified against the code.

Business systems

Business systems
System	Status	What the code does
Fortnox	Live	OAuth, articles, customers, orders, invoices, stock mirror, stocktaking export. Mirrored into Leara. Retry on 429.
Visma eEkonomi	Planned	On the price list. No live adapter in the platform.
Visma.NET / Business NXT	Planned	On the price list and roadmap. No live adapter.
Microsoft Business Central	Planned	On the price list. No live adapter.
Jeeves, Garp	Planned	Named as candidates. Not built.
SAP, Hogia	Not in catalogue	No adapter. CMS pages on the website are not proof of a connector.
Spiris	Prototype	An in-house bookkeeping experiment under prototypes/. Not a customer product. The in-app catalogue showing “available” is wrong.

E-commerce

E-commerce
System	Status	What the code does
Shopify	Live	OAuth. Products, customers, orders. Read and write scopes. Webhooks.
WooCommerce	Planned	On the price list and in entitlements. No adapter in core.
Norce, Litium, Centra	Not in catalogue	Named as examples in channel UI. Not live connectors.

Shipping and payments

Shipping and payments
System	Status	What the code does
Fraktjakt	Live	Booking, tracking, webhook. Per-account keys in the database. The practical path toward PostNord.
PostNord	Partial	Sales name on the price list. Freight via Fraktjakt. ZPL labels in Device Manager are stubbed. Outward packaging is specified in a demo.
nShift	Planned	On the price list. No live adapter. Dummy “available” in the app does not count.
Budbee	Not in catalogue	Appears as a CMS page. No adapter.
Kustom	In code	Payment mirror: status, capture, refund, webhook. Leara is not a PSP. Checkout stays in the shop. Commercial packaging is specified in a demo.
Adyen, Stripe	Not in catalogue	No platform connector. Stripe appears in internal admin billing and as a choice in the POS prototype — not as a customer integration.

Other items not sold as integrations

Sinch and Mailgun run platform email and SMS (invite, password, notice). Not a customer-facing communications product.
HubSpot, Voyado, and Salesforce sit as dummy rows in the app catalogue. Not product.
ERP is meant to become swappable adapters behind the same port. Today Fortnox is the one that is built.

What can be said with evidence

What lacks evidence is labelled not specified — not as a certification. No ISO or SOC claims. No SLA figures without a contract.

Access and tenancy

Sign-inLive: Account users sign in with JWT against the platform API. The same issuer for the print service, scoped per account.
TenantLive: The key is accountId. Database documents belong to an account. Fortnox-mirrored rows bind with a compound id of account plus Fortnox number.
UsersLive: A master user can create sub-users. Entitlement (what the account bought) is separate from permission (what the user may touch). A finer role matrix beyond that is specified in a demo — not as an RBAC product sheet here.
AppsLive: Web, iOS, and Android are gated by licence surfaces. The warehouse package unlocks mobile. Stocktaking requires a checked-in device at close.

Hosting and traffic

Production runs in AWS region eu-north-1 (Stockholm). Database on MongoDB Atlas. EU data residency without a certification stamp here.
The web reaches you over HTTPS. How TLS looks between CDN and origin is not published as a guarantee — details in a demo.
Customer Fraktjakt keys are stored per account in the database, not in application config.
Webhooks: Shopify; Fraktjakt with verification; internal mirroring to Leara admin with HMAC and retry. Incoming admin calls require an API key.

Audit and inventory

Stocktaking has an immutable event log. Each count carries an opId and can be replayed without double-counting. Force-close leaves an audit. The pattern is built for stocktaking — not claimed for the whole platform.

Reliability

Sync with FortnoxLive: A mirror in Leara. Write queues for article, order, invoice, quote, customer. Retry and backoff on 429. Reconciliation with email alerts.
Offline stocktakingLive: The phone writes durably to disk before HTTP. The same opId on resend. Close is blocked until the device queue has drained. Live fan-out between nodes via database change streams.
PrintingPartial: Jobs queue against the agent and send when it is online. PostNord ZPL is stubbed.
HealthLive: Health checks on the API. Stocktaking has a separate wellness surface (a stuck export must not fail the load balancer). Email alerts for export, quarantine, and Fortnox reconciliation.
Backup and on-callNot specified here: Atlas is used in production. Backup schedule, restore tests, on-call, and scaling are not published here. Walk through operations in a demo or contract.
SLANot specified here: Figures live in the contract, not on this page. Urgent production issues are prioritised via support.

The office on the web. The floor in the app.

Same account, same stock. Different hands. The web owns what should not happen from a handheld in the aisle.

Web

The main surface for owners: dashboard, products, customers, orders, quotes, invoices, inventory, starting and closing a stocktake, purchasing, apps, and account. Only the web starts and closes a stocktake. That is a decision, not a gap. The web is online — an uncertain write is phrased as unconfirmed, never as “was not saved”.

iOS

Native SwiftUI. Tabs: Home, Orders, Pick list, Warehouse, Stocktaking, Purchasing. Camera for barcodes. Stocktaking writes to disk before the network. Forced dark theme, the same picture as Android.

Android and handheld

Native Jetpack Compose. The same flows as iOS. Camera plus hardware scanner — DataWedge on Zebra. Dedup so keyboard wedge and broadcast do not double-count the same physical scan. Shared handheld: the queue survives sign-out and is stamped with an owner. Warehouse Pro includes Android.

App Store and Play links on this site show as “coming soon” until the listings are public. The apps exist in code and run against the API.
Stocktaking on an upgraded handheld has an operations checklist — Å/Ä/Ö search is correct only after catalogue sync. That is operations detail, not marketing.

Printing

A cloud service pairs a local agent with a six-digit code. Print jobs queue to printers on the LAN — typically Zebra over port 9100 — without a public IP. The agent is close to production. PostNord ZPL is stubbed. Say label printing in operations, not a separate product name toward the market.

What is not an app yet

POS / tillPrototype: An iPad prototype under prototypes/. Creates a Fortnox invoice via the API. Delayed as a product. Not SoftPOS.
Partner portalPrototype: A prototype against internal admin. Partners can onboard in that picture — not a public self-service surface on this site.

Product guide