One stock truth across Amazon, Flipkart and Shopify — a ledger-based inventory system
How Yukti AI replaced Excel with a real inventory and dispatch system for Backdrop India, a manufacturer selling 650+ product variants across three marketplaces — automated order-file ingestion, a mapping layer for messy marketplace SKUs, a stock model where every change is an auditable ledger entry, and one Ready to Dispatch queue.
Backdrop India manufactures photography backdrops and sells them on Amazon, Flipkart and Shopify with over 650 variants. Stock lived in Excel, each marketplace used different, often misspelled SKUs, and orders were reconciled by hand. Yukti AI built a system with one internal variant catalogue, a channel-SKU-map that translates each marketplace's messy identifiers, n8n workflows that parse the order files each channel exports, a combined dispatch queue, and a ledger-based stock model — stock is never edited directly; it is derived from every dispatch, return and adjustment.
Quick facts
| Client | Backdrop India |
|---|---|
| Industry | Manufacturing + e-commerce — photography backdrops |
| Scale | 650+ product variants, sold on Amazon, Flipkart and Shopify |
| Core challenge | Stock in Excel; three marketplaces with inconsistent, misspelled SKUs; orders reconciled by hand; no audit trail on stock |
| Solution | Custom ledger-based inventory & dispatch system with automated marketplace order ingestion |
| Key components | Internal variant catalogue, channel-SKU-map, per-marketplace n8n parsers, Ready to Dispatch queue, stock ledger, returns handling, hold / priority states, analytics |
| Stock model | Stock is never edited directly — every dispatch, return and adjustment is a ledger row; the count is derived |
| SKU handling | No assumed matches — every marketplace line resolved via the channel-SKU-map; unmatched lines go to a manual queue, never dropped |
| Stack | Static HTML / CSS / JS frontend, ApexCharts, Supabase (PostgreSQL, triggers), n8n |
| Result | One stock truth across three channels; orders ingested automatically; a fully auditable inventory; a single dispatch queue |
Selling the same product in three places, none of which agree
Backdrop India makes photography backdrops — printed fabric and vinyl in many sizes and designs, over 650 sellable variants. The same physical piece is listed on Amazon, on Flipkart and on the company's own Shopify store. Each of those platforms has its own idea of what that piece is called.
Amazon's SKU for a design might be spelled one way; Flipkart's another; Shopify might not carry a SKU at all, just a title. So when an order comes in from each channel, someone has to work out which of the 650 internal variants it actually refers to, deduct that from a stock figure in a spreadsheet, and hope nothing was missed. Multiply that by three channels and hundreds of orders, and the spreadsheet is always slightly wrong — which means overselling, cancelled orders and marketplace penalties.
A multi-marketplace inventory system's whole job is to be one stock truth that every channel draws from — and to translate each channel's messy language into that one truth without a human doing the lookup every time.
What Excel could not do
- "Every marketplace calls the product something different." Misspellings, different formats per channel, and Shopify sometimes with no SKU at all.
- "Orders are matched to stock by hand." A person deciding which internal variant each marketplace line means, hundreds of times a day.
- "When the stock number is wrong, there's no way to know why." A spreadsheet cell has no history.
- "Held orders get lost." Orders with a payment or address problem sat in limbo with nothing to bring them back.
- "There's no combined view." "What do we need to pack today" meant checking three places.
How dispatch day changed
Before
- Stock figures maintained in Excel
- Marketplace SKUs matched to variants by a person
- Orders checked across three platforms separately
- Stock edited directly — no history when it went wrong
- Held orders had no path back into the flow
After
- One internal variant catalogue; one derived stock count
- Channel-SKU-map resolves every marketplace line automatically
- One Ready to Dispatch queue across all channels
- Every stock change is a ledger row — full audit trail
- Released held orders flagged priority, surface to the top
Why a custom build, not an off-the-shelf inventory app
There are multi-channel inventory tools. They tend to assume tidy, matching SKUs, charge per order or per channel, and give you their dashboard and their stock model. Backdrop's reality — hundreds of variants, three channels that each name products differently, Shopify orders with no SKU at all — is exactly where a generic tool needs constant manual correction. A custom build made the messy-SKU handling and the auditable ledger the core of the system, not a workaround.
| What a multi-marketplace manufacturer needs | Off-the-shelf inventory app | The system we built |
|---|---|---|
| Handle misspelled / missing marketplace SKUs | Assumes clean matches; mismatches error out | channel-SKU-map + manual queue, nothing dropped |
| Auditable history of every stock change | Usually a single editable number | Ledger-based — count is derived, never edited |
| Parse each marketplace's own order file | Generic import, breaks on format quirks | A dedicated n8n parser per channel |
| One dispatch queue across channels | Often per-channel views | One combined Ready to Dispatch list |
| Held-order recovery | Manual | Hold state + priority flag on release |
| Cost | Per order / per channel, monthly | One-time build, then a small annual charge |
From a marketplace file to an updated stock count
The components
The internal variant catalogue
One record per real sellable variant, with a consistent internal SKU format ([PREFIX]-[PRODUCT]-[SIZE], e.g. BI-RHA-5x6). This is the single catalogue every channel maps back to. Benefit: there is exactly one answer to "what is this product", regardless of which marketplace an order came from.
The channel-SKU-map
A mapping table from each marketplace's SKU or title to the internal variant. The system never assumes a direct match — every marketplace order line is resolved through this map. Anything that doesn't match goes to a manual-mapping queue, where a person maps it once and every future order for that SKU flows automatically. Benefit: no order is ever silently dropped because a marketplace spelled something wrong.
Per-marketplace order ingestion (n8n)
An n8n workflow per channel reads the order file that channel exports — Amazon and Flipkart as spreadsheets, Shopify as CSV — maps each line through the channel-SKU-map, and inserts the orders and order items into the database. Benefit: orders arrive in the system without anyone typing them in.
The Ready to Dispatch queue
One combined list of everything ready to pack, across all three channels. Orders with a payment or address problem sit in a hold state; when a held order is released, it is flagged priority so it surfaces to the top of the queue and triggers a notification. Benefit: the packing team works one list, and nothing that was held is forgotten.
The stock ledger
The heart of the system: stock is never changed directly. Every movement — a dispatch, a return, a manual adjustment, a production addition — is a row in the stock ledger, and the current inventory count is derived from that ledger. All stock-affecting writes go through a database function, never ad-hoc updates from the frontend or from n8n. Benefit: when a number looks wrong, the exact history of what changed it is right there — and it usually isn't wrong.
Dispatch & returns
Clicking dispatch on an order fires a database trigger that writes a dispatch entry to the ledger, updating the derived count. A received return writes a return entry the same way. Benefit: stock moves as a consequence of a real action, not a separate bookkeeping step.
Analytics
Reporting on stock levels, dispatch volume and channel performance, with ApexCharts. Benefit: the picture across all three marketplaces on one screen.
Where AI extends a multi-marketplace inventory system
Backdrop's build is automation-first — the marketplace ingestion and the trigger-driven ledger already remove most of the manual work. An AI layer, added on top, works from the same clean data:
- SKU-match suggestions — for the manual-mapping queue, the AI proposes the most likely internal variant for an unmatched marketplace SKU or title, so a person confirms rather than searches.
- Reorder / production alerts — which variants will run out based on the sales rate across all channels, before they do.
- Anomaly detection — a sudden spike in returns on one design, a channel whose order pattern changed, a variant selling far above its norm.
- Plain-language questions — "which designs are overstocked", "what's our dispatch backlog by channel", "which variants had the most returns last month".
What runs without anyone pressing a button
Marketplace order file → orders in the system
Dispatch click → auditable stock change
Held order released → jumps the queue
Unknown marketplace SKU → nothing lost
How it was built
Model the catalogue & the ledger
One internal variant catalogue with a consistent SKU format, and a stock-ledger schema with the rule that no stock value is ever written directly.
Wire the frontend to real data
The approved static frontend connected to Supabase — edited in place, not rebuilt — with all stock writes routed through a database function.
Build the SKU-map & ingestion
The channel-SKU-map, then an n8n parser per marketplace that reads the order file, maps each line, and inserts orders — with unmatched lines to a manual queue.
Dispatch, holds & triggers
The Ready to Dispatch queue, hold and priority states, and the database triggers that turn a dispatch or a return into a ledger entry.
Iterate
Three-plus rounds of refinement against real order files and real edge cases — the messy-SKU reality only fully shows itself in production data.
What changed
Factual — no invented numbers.
Technology & data architecture
- Static HTML / CSS / JavaScript frontend — lightweight, no build step, edited in place against the approved design.
- Supabase (PostgreSQL) — the database, with stock logic enforced by database functions and triggers so the frontend and n8n can never write stock directly.
- n8n — self-hosted, one order-file parser workflow per marketplace.
- ApexCharts — reporting; Lucide icons.
Data integrity rules
- Stock never changes directly — every change is a
stock_ledgerentry, and that ledger is the audit trail - All stock-affecting writes go through a database function, never ad-hoc updates
- Marketplace SKUs are never assumed to match — always resolved via the channel-SKU-map
- Unmatched order lines go to a manual queue, never silently dropped
- Backdrop owns all data; Supabase keys are environment variables, never committed
If you sell the same stock in several places, this is buildable for you
A ledger-based stock model, a marketplace-SKU mapping layer and automated order-file ingestion fit any manufacturer or brand selling across multiple channels:
- D2C brands on Amazon, Flipkart, Meesho, Myntra and their own store
- Manufacturers who wholesale and sell direct
- Businesses with many size / colour / design variants of the same product
- Any operation where "how much do we actually have" is currently a spreadsheet
Start with a free workflow audit. See Replace Excel & Tally, Custom ERP Software or AI Business Management System.
Questions marketplace sellers ask
Explore more
Replace Excel & Tally
Move the operation off spreadsheets to one system that stays correct.
Custom ERP Software
Inventory, orders, production and dispatch built around how your business actually runs.
Workflow Automation
n8n workflows that move data between marketplaces, your systems and your team.
Case study: Splenzo Polyfab
An AI-powered ERP for a woven-bag plant — stage-wise production, quality and inventory.
Textile & Apparel
Inventory, catalogue and marketplace operations for Surat's textile and apparel businesses.
All case studies
Every Yukti AI build — jewellery, manufacturing, trading and services.
Summary
Yukti AI replaced Excel with a custom ledger-based inventory and dispatch system for Backdrop India, a photography-backdrop manufacturer selling over 650 product variants on Amazon, Flipkart and Shopify. The system centres on one internal variant catalogue with a consistent SKU format, a channel-SKU-map that resolves each marketplace's inconsistent and sometimes missing SKUs to internal variants (unmatched lines go to a manual queue, never dropped), and n8n workflows with a parser per marketplace that ingest the order files each channel exports. Orders flow into one combined Ready to Dispatch queue with hold and priority states; clicking dispatch fires a database trigger that writes to a stock ledger, from which the current inventory count is derived — stock is never edited directly, giving a full audit trail. Built on a static HTML/CSS/JS frontend, Supabase with database triggers, ApexCharts and n8n. Yukti AI builds comparable multi-marketplace inventory systems for D2C brands and manufacturers across India.