The platform
One set of records, and every surface that reads them
Akkad is a business operations platform built around inventory. Underneath everything there is one catalogue, one stock ledger, one order book, one customer list and one set of pricing rules. The apps, the counter, your online store and your landing pages are surfaces onto those records — not separate systems that have to be reconciled at the end of the week.
Most business software is assembled from parts that were built separately: stock in one place, sales in another, the website somewhere else again, and a nightly export holding them together. The joins are where the errors live. An item sells online while the shelf figure lags, a promotion behaves differently at the counter than it did in the browser, and a report disagrees with the money in the drawer.
Akkad is built the other way round. There is one item record, and it is the same record whether it is scanned at the counter, listed on your storefront, sold through a landing page or received against a purchase order. There is one stock figure per item — or per variant, or per batch when you are tracking lots — and every path that changes it writes to the same place, under the same locks, leaving the same audit line behind.
That single spine is what makes the rest of this page possible. Pricing rules can be written once and applied on every channel because there is one place to apply them. A report can reconcile with the cashbox because both read the same definition of money moved. This page walks the whole platform, area by area.
01
One catalogue, one ledger, many surfaces
The shape of the product is easy to state. In the middle sit the records: items and their categories, stock, orders, customers, and the rules that price them. Around the outside sit the surfaces that read and write those records — the admin apps on six platforms, the counter, the storefront, landing pages, the courier integrations and the reporting layer.
Nothing in the middle belongs to a surface. An order created at the counter, one placed on your storefront and one typed in by a member of your team are the same kind of record with a different source stamped on it. They appear in the same list, deduct from the same stock, obey the same pricing rules and land in the same reports.
- Every business endpoint is scoped to one organisation and checked for membership and permission on every request.
- Stock derives upward: a variant's stock is the sum of its batches, and a parent item's stock is the sum of its variants. Derived numbers are never independently written.
- Orders carry their source — internal, counter, storefront or landing page — plus which storefront they came from, so channel reporting is a filter rather than a separate system.
02
The platform in numbers
- 39
- permission grants, each individually assignable
- 9
- reports, each behind its own permission
- 7
- Iraqi courier integrations
- 5
- storefront templates
03
Catalogue and stock
The catalogue is the part everything else depends on, so it carries the most structure: three item types, per-variant pricing and stock, packs that share one pool, and lot tracking with expiry when you need it.
Three item types
Simple items, variable items on a single axis such as size, and configurable items on two levels — an attribute like a colour owning its own set of variants. Up to 200 variants and 50 attributes per item, each with its own SKU, barcode, image, stock and prices.
Pack sizes
Sell the box and the single from one item and one stock pool. Each pack carries its own barcode and its own price, so a carton can be cheaper per unit than the loose units it contains, and both draw from the same budget.
Batches and expiry
Opt in per item. Each lot carries its own cost and expiry date, deduction is first-expiry-first rather than plain first-in-first-out, and cancelling an order returns units to the exact lots they came from.
Real cost of what shipped
After a batch deduction the order line's cost becomes the weighted average of the lots actually consumed, and re-receiving an existing lot averages the new cost in. Margin reflects the stock that left the shelf, not a stale figure.
Categories that keep history
Two levels, with images and slugs. Deleting a category moves its items to Uncategorised and repoints historical order lines, so nothing in your past is orphaned by a tidy-up.
Scanner-first search
An exact-match probe runs in strict order — item barcode, variant barcode, pack barcode, item SKU, variant SKU — and a pack barcode tells the app which pack to pre-select. Text search adds typo rescue and folds Arabic-Indic digits to Latin.
Suppliers and purchase orders
Supplier details are snapshotted onto each order so history stays accurate after an edit. Receiving posts stock and creates or merges batches; reversal is supported down to part of a line, and refuses if units from that lot were already sold.
Import, export and images
Spreadsheet import across 31 recognised columns, including variants and multiple pack sizes as continuation rows. Images arrive by ZIP, matched to items by filename against SKU or barcode, up to 250 per file.
An audit line for every movement
Every stock change records who did it, when, and the figure before and after. Log entries are stored as keys and variables rather than sentences, so history renders in the reader's own language.
04
Selling
Four ways to take an order — your team, the counter, your online store and single-product landing pages — all writing into the same order book, all priced by the same rules.
The order book
Six statuses, split into a group that holds stock and a group that releases it, so moving an order between them deducts or restores automatically and re-checks availability first. Editing writes a readable, localised change log.
The counter
Drawer sessions with an opening balance and a close that reconciles cash, card and split tenders. Up to 30 pinned quick-sale tiles, hardware barcode scanning through plain keyboard input, and four scan modes including scan-to-return.
Your online store
A storefront on your own subdomain or a custom domain with automatic certificates, built from five templates and four style presets over six independently overridable controls. An organisation can run several stores, each with its own look, language and visible categories.
Landing pages
One product, one page, its own form, its own pixels and its own payment mode — for the offer you are running this week rather than the whole catalogue. Two templates, including a direct-response layout with merchant-authored content blocks.
Pricing rules
Four ways to measure a cart and three ways to discount it, written as ladders of brackets, scoped to categories and targeted per channel. Including a discount expressed as a share of your margin rather than a share of the price.
Promo codes
A separate lever from rules, validated per channel as the customer types, additive to whatever the rules already gave and clamped to the remaining subtotal.
Online payments
Card payment on your storefront through your own Al Qaseh account, so funds go straight to you. The cart is priced entirely server-side into an intent, and no order exists until the payment is verified by calling the provider back.
Shopper accounts
Optional or required sign-in with Google or Apple, through a single broker so every subdomain and custom domain can offer it without registering its own origins. Shoppers get an order history, favourites and reviews.
Ad measurement that waits
Meta and TikTok pixels per store and per landing page, plus server-side conversion events that can fire when an order reaches processing or delivery rather than at checkout — because in a cash-on-delivery market, optimising for orders placed means optimising for orders never paid.
05
Fulfilment
Delivery pricing and courier handoff, built for markets where the address is a landmark, the money arrives at the door, and city names are spelled five different ways.
Four kinds of shipping rule
A flat rate, brackets on the number of packs, brackets on the order total, or a per-city price list. Free delivery is simply a bracket with a cost of zero and no upper bound.
The cheapest applicable rule wins
Every eligible rule is evaluated and the lowest result is taken, so a free-delivery-over-threshold rule automatically overrides a standing flat rate without anyone having to switch one off.
City matching that forgives spelling
Names are normalised — diacritics stripped, letter variants folded, the definite article removed — then matched exactly, by containment, or by similarity. So three spellings of the same city price identically.
Seven couriers
Al Waseet, Modon Express, Hi-Express, Al Zaeem, Alsai, Tasheel and Prime. Each is validated without saving, and Prime works on built-in credentials so there is nothing for you to enter.
Live city and district lists
Every integration returns the courier's own address tree as a standard list, so checkout offers the cities and districts that courier will actually accept.
Status reconciliation
Tracking numbers are queried in batches and each courier's vocabulary is normalised into four buckets. Only a confirmed delivery writes back to the order; anything unrecognised is marked for review rather than guessed.
Cash on delivery, computed
The amount the courier collects is zero when the order was genuinely paid online through the gateway — and only then, so marking an order paid by hand never changes what is collected at the door.
Bulk dispatch
Ship a selected set or every processing order in one sweep. Members whose visibility is restricted can only sweep the orders they can see.
Errors you can act on
Courier failures are translated into readable messages carrying the courier's own rejection reason. Emoji are stripped from free-text fields before sending, because several courier backends reject them silently.
06
Money
What was sold, what was collected, and what is still owed are three different questions. Akkad answers them from one ledger rather than three sets of numbers that drift.
The debts ledger
One row per movement of money, with a signed amount — positive collected, negative refunded — so every total is a plain sum. Rows are append-only: a refund is a new row, never an edit of an old one.
Who owes you
A live debtors list, biggest first, computed from the orders themselves rather than a cached column, with a full statement per customer showing every unsettled order and every payment against it.
Instalments
A plan is an agreement, not a second ledger: a down payment, a count, an interval. Amounts split evenly with the remainder on the last row so the parts always sum back, and a payment schedule is answered by allocating the one collected total in order.
The drawer
One open session per person. Closing computes expected cash from every linked order — including the cash half of split tenders — and compares it to the counted drawer. Totals are cached on the session so the summary can be reprinted later.
The cashbox
A per-year money box across cash, card and bank, tracking what you physically hold rather than what you invoiced. Payments land in the year they were collected, so an instalment paid next March belongs to next year's box.
Expenses and incomes
Fixed or per-order, scoped to categories or the whole business, spanning a date range and prorated across it. The same proration function feeds both the sales report and the financial report, so the two cannot disagree.
The financial report
Money in against money out for a month or a year, with a separate profit block on analytics rules, and a grouped breakdown of where the money went that always sums back to the total.
Cash rounding
Round up, down or to nearest at a unit you choose, applied last in the total so it lands on the figure actually handed over. A positive total can never round to zero.
Caches are never the truth
Balances and amounts paid are stored for speed but written only alongside the ledger. Anything a customer might argue about — a statement, a receipt — is recomputed from the ledger rather than trusting the cache.
07
Intelligence
Nine reports, each behind its own permission, so you can hand someone the numbers they need without handing over the whole business.
Today
Orders, units sold, revenue and catalogue size for the day, with a seven-day revenue sparkline whose day boundaries are your local midnight rather than the server's.
Sales performance
Orders, revenue, cost, gross and net profit, margin, tax, shipping and discounts over any range — plus revenue and order counts across all 24 hours, so you can see which hours actually earn.
Inventory performance
Your items ranked by quantity sold, with current stock beside the sales figure, an optional category filter and a per-variant breakdown when variants are combined.
Categories performance
Sales, cost, inventory value and profit per category, with order-level revenue distributed proportionally so categories always reconcile back to the sales report.
Team performance
Orders and value per team member with a full status breakdown, respecting the same visibility restrictions the rest of the platform enforces.
Expiry and stock
Four exclusive tiers from expired through the next quarter, with units at risk and the value at risk behind them, priced from batch cost where it exists.
Stock health
Five buckets from out of stock to overstock, driven by a sales velocity capped at the item's own age so new items are not understated. It reports lost revenue per day and capital tied up — and deliberately stops there rather than prescribing what to order.
Cities performance
Revenue by governorate, grouped from the free-text city on each order by the same fuzzy matcher shipping uses, with the actual spellings seen listed beside each city.
Financial report
Money in and money out for the period, net flow, and a profit block computed on analytics rules — two rulebooks, deliberately, because collected and earned are not the same number.
08
Operations
The parts that decide whether the platform survives contact with a real business: who can see what, what happens when the connection drops, and what comes out of the printer.
Permissions
39 individual grants across orders, items, reports, finance, people, settings, export and online presence — including a separate grant just for seeing cost prices.
Visibility restrictions
Four optional limits on top: no editing finalised orders, no setting finalised statuses by hand, and scoping a member to specific categories or to specific order creators. Hidden records return not-found rather than forbidden, so the interface does not become a directory of what you cannot see.
Offline
A local database on the device keeps the catalogue, customers, today's orders, tables and pinned items. You can sell, open and close a drawer, and add dine-in rounds with no connection at all.
A queue that never loses work
Queued work flushes in a fixed order so orders always attach to a real session. Transient failures retry indefinitely, a persistently rejected order becomes visible with a one-tap retry, and nothing is ever discarded.
Printing
Invoices on A4 or Letter, shipping labels at two sizes, receipts on 80 mm or 58 mm thermal — with around 45 toggles deciding what appears, a per-template language, and bulk label printing with a quantity per item.
Kitchen stations
Named network printers mapped to categories, with a fallback station that catches anything unassigned so a ticket is never silently dropped.
Notifications
New orders, low and out of stock, expiry digests and subscription notices — each localised to the recipient's own language and mirrored into an in-app inbox. Order alerts respect visibility restrictions, so nobody is notified about an order they cannot open.
Apps on six platforms
Android, iOS, web, macOS, Windows and Linux from one codebase. Desktop builds update themselves through signed feeds; mobile prompts when a store version is newer.
The medicine library
18,669 medicines with English and Arabic names, mapped one-to-one onto item fields — so importing one creates the item and its strip-and-box packs with both barcodes already attached.
09
Where it runs
- 6
- platform targets per app
- 4
- editions from one codebase
- 13
- in-app languages
- 14
- storefront languages
10
The idea underneath all of it
A preview and a charge can never disagree
A customer sees a total in a browser. A cashier sees a total on a screen. The server decides what is actually charged. In most systems those are three separate pieces of arithmetic written by three different people at three different times, and the gap between them is where arguments with customers come from. In Akkad they are deliberately the same logic, executed in the same order, wherever it runs — and where they cannot literally be the same code, they are mirrored line for line and treated as one thing to change.
One fixed order of operations
Products total, then rule discounts, then shipping, then tax on the taxable portion only, then the promo code, then any custom amount, and cash rounding always last. The same sequence in the storefront preview, in the apps and on the server.
The city matcher exists in six places and behaves identically
The storefront, landing pages and all four apps carry the same normalisation and matching algorithm as the server, so the delivery cost quoted at checkout is the delivery cost charged.
Rounding matches the client's arithmetic on purpose
Rounding to nearest uses half-away-from-zero specifically to match how the apps round, rather than the server language's default. A one-unit disagreement in a receipt is a small bug and a large loss of trust.
The server never trusts a client amount
Cart prices, pack prices and rounding are all recomputed at order creation from your own records. A preview is a preview; the record is the record.
An app that cannot compute a rule is not sent it
Newer rule types are withheld from older installed builds, because an old build would misread the rule and fire it on nearly every order. No discount is a better failure than the wrong discount.
11
How one order touches everything
The areas above are not really separate. Here is a single storefront order passing through them.
- 1
The item is found
A shopper lands on your storefront and adds a box of twelve to the cart. The line records twelve base units, one pack, and the pack's own price — because that is how the item is priced, not a multiplication done in the browser.
- 2
The cart is priced
Pricing rules are evaluated against the categories in the cart. Where a rule is margin-based, the storefront asks the server for the quote instead of computing it, so your cost prices never reach the browser.
- 3
Delivery is calculated
Shipping rules run against the recipient's city and the number of packs. Every eligible rule is evaluated and the cheapest result is taken. If the shopper picked the city from a courier's own list, the server re-resolves that name from the courier rather than trusting what came back.
- 4
The order is created once
The submission carries a client-generated key. A retried submit — a lost response, a double tap, an offline queue flushing twice — returns the original order rather than creating a second one and deducting stock again.
- 5
Stock moves
The order lands in a status that holds stock, so units are deducted under a row lock. If the items are batch-tracked, the deduction is first-expiry-first, an allocation record links each lot to the line, and the line's cost becomes the weighted average of the lots consumed.
- 6
It goes to a courier
You dispatch it, alone or in a sweep. The courier receives the recipient details in their format, the amount to collect at the door — zero if it was already paid online — and a goods description derived from the order's categories. The tracking number comes back onto the order.
- 7
The money is recorded
Payment writes a signed row to the ledger. The customer's balance and the order's paid amount follow in the same transaction, the cashbox counts it in the year it was collected, and the sales and financial reports read it through the same definitions.
12
Decisions that shape everything else
A handful of choices recur in every area of the platform. They are worth stating plainly, because they explain most of the behaviour you will meet.
Derived numbers are derived
A parent item's stock is the sum of its variants, and a variant's stock is the sum of its batches. Neither is ever written directly, so the aggregate and the detail cannot fall out of step.
Nothing is deleted quietly
Deleting a category repoints its historical order lines. A batch with allocations cannot be removed. A table with an open order cannot be deleted, and past orders keep the table's name as it was. History outlives the thing it refers to.
Failures are named rather than guessed
An unrecognised courier status becomes needs-review, not delivered. An item with no recorded cost contributes no margin to a profit-based discount. Where the system does not know, it says so instead of inventing a plausible number.
Replays are expected, not exceptional
Order creation, dine-in rounds and debt payments each carry an idempotency key with a database constraint behind it. A connection that drops at the wrong moment is a normal event in the field, so it is designed for rather than patched around.
Every business record belongs to exactly one organisation
Membership and permission are resolved on every request before anything is read — including the offline bulk-sync endpoint, which validates membership explicitly rather than trusting the identity in the token.
What Akkad is not
Stock is a single figure per item, variant or batch, scoped to one business. There is no warehouse, branch or location model, and no stock-transfer feature — if you run several stock pools that must be tracked separately, this is not built for that yet. Batches are lot-level, not unit-level, so there is no serial-number tracking. SKUs and barcodes are never generated for you. Knowing this before you start is worth more than discovering it in month three.
13
Where each surface lives
One platform, several addresses. Which one you use depends on who you are and what you are doing.
| Surface | Runs on | Who it is for |
|---|---|---|
| Admin apps | Android, iOS, web, macOS, Windows and Linux, at inventory, pharmacy, restaurant or supermarket .akkad.io | You and your team — catalogue, orders, money, reports, settings |
| The counter | Inside the same apps, on a till, tablet or phone with any keyboard-style scanner | Whoever is serving the person in front of them |
| Your online store | Your own subdomain, or your own domain with certificates issued automatically | Your customers, browsing and buying |
| Landing pages | A path on the same subdomain or custom domain, one page per product | Traffic from a specific campaign, pointed at one offer |
| The shopper area | Inside your store, once sign-in is switched on | Returning customers — order history, favourites, reviews |
The storefront and landing pages are served only while your plan covers them. When it does not, the page returns a temporary-unavailability notice — your published setting is never altered, so restoring the plan restores the exact same site.
14
Questions
Do I have to use all of this?
No. Batch tracking is opt-in per item. Debts, instalments, offline mode, negative stock and cash rounding are settings you switch on when you need them. A business that just wants a catalogue, stock and orders can ignore most of this page and turn things on later without migrating anything.
Does the online store see the same stock as the counter?
Yes — it is the same figure. There is no synchronisation step between them, because there is nothing to synchronise. An order from either side deducts from the same record under the same lock.
What happens when the internet drops mid-shift?
The apps keep working from a local copy of the catalogue and customers. Orders, drawer sessions and dine-in rounds queue locally and flush in a fixed order when the connection returns. Editing items and importing are blocked offline, deliberately, because those cannot be reconciled safely afterwards.
Can I give someone access to sales figures without showing them what I paid?
Yes. Seeing cost prices is its own permission, separate from every report grant, and each of the nine reports has its own grant as well. You can also scope a member to specific categories or to specific order creators.
Is any of this specific to one country?
The courier integrations and the city report are built for Iraq, and phone validation only enforces the local format when your business is set to Iraq. Everything else — catalogue, stock, orders, pricing, money, reports — is general, in 13 in-app languages and 14 on your storefront.
Where does my data live relative to other businesses?
Every business record carries an organisation, and every request resolves membership and permission for that organisation before reading anything. Records outside your organisation are not filtered out of your results — they are never in scope to begin with.
Start anywhere
Catalogue
Item types, variants, pack sizes, categories and the import path — the records everything else reads.
Online store
Five templates, style presets, custom domains with automatic certificates, and everything the storefront does.
Reports
The nine reports, what each one measures, and why the money numbers reconcile with each other.
اسے اپنے ہی کیٹلاگ پر آزما کر دیکھیں
اپنے لیے موزوں پلان سے شروع کریں، اشیاء ایکسل فائل سے درآمد کریں، اور اسی دن چلتا ہوا اسٹور، کاؤنٹر اور آرڈر بک حاصل کریں۔
مفت پلان دستیاب ہے۔ آزمانے کے لیے کارڈ کی ضرورت نہیں۔ درآمد آپ کا موجودہ کیٹلاگ آپ کے ساتھ لے آتی ہے۔