What to Build for a Steel and Metals Trading Business

For: Owner or COO of a mid-size steel or metals trading firm in India — 50–500 Cr annual turnover, running 3–8 depots, whose business still operates on a combination of Tally, WhatsApp order threads, and manually updated rate sheets, and who is losing margin to competitors who quote faster and reconcile stock more accurately

For a 50–500 Cr steel or metals trading firm running on Tally, WhatsApp and a manually updated rate sheet, the software worth building custom is narrow and specific: a live rate engine that pushes mill and LME revisions to every salesperson's quote screen within minutes, a depot stock system where the number on the screen matches what is actually in the yard, and an invoicing layer that calculates GST TDS, RCM on unregistered purchases, and the raised TCS on scrap correctly on the same invoice. Everything else — accounting, payroll, basic CRM — stay on the tools you already have. This post walks through why those three, in that order, and what a build actually looks like.

The reason no off-the-shelf ERP fits is not that they lack modules. It is that they were designed for manufacturers with a bill of materials or retailers with SKUs that do not reprice mid-shift. Steel trading has three realities that break generic systems: intraday price volatility from mills and the LME, multi-depot stock where the paper number and the yard number drift apart every week, and a tax stack — GST, RCM, TDS on scrap, TCS on high-value sales — that changed materially in late 2024 and again in April 2026, and that most ERPs handle by bolting on custom fields your CA maintains in a spreadsheet.

The three problems that cost you real money

1. The 6–18 hour lag between mill revision and corrected rate sheet

This is the single biggest source of invisible margin loss in Indian metals trading, and almost no owner tracks it directly. A mill revises TMT or HR coil rates in the morning. Your purchase head sees it on WhatsApp. The updated sheet reaches depot sales by afternoon — sometimes the next morning. In between, your salespeople quote yesterday's number to walk-in and phone customers, and the business absorbs the delta silently across dozens of transactions. On a 200 Cr turnover with a 3% gross margin, a recurring 30-paise-per-kg quoting lag on even 15% of volume is not a rounding error.

You cannot fix this with training or discipline. The quoting environment has to be structurally incapable of showing a stale rate.

2. Stock that exists on paper but not in the yard

Every mid-size trader has this. The Tally stock says 42 tonnes of 12mm TMT at Depot 3. The yard has 38. The four tonnes went out on a partial delivery that was invoiced against a different grade, or they were transferred and the GRN never made it back. Salespeople quote confidently, promise delivery, and then scramble. Customers who have been burned twice stop calling.

The problem is not a lack of stock registers. It is that the register and the yard are updated by different people at different times, and nobody's compensation depends on them matching.

3. A tax stack that changed under your feet

Since October 10, 2024, GST Notification No. 25/2024-CT mandates 2% TDS on all metal scrap B2B transactions exceeding ₹2.5 lakh across Customs Tariff Chapters 72–81, with monthly GSTR-7 filing. In the same notification, purchases from unregistered suppliers attract 18% GST under Reverse Charge Mechanism. And from April 1, 2026, income-tax TCS on sale of scrap rose from 1% to 2% under Section 394(1) of the Income-tax Act, 2025. Three overlapping triggers, all live on the same invoice, all changed within 18 months. Your accountant is reconciling manually. Your ERP, if you have one, was configured before any of this existed.

None of this is optional. A misfiled GSTR-7 or a missed RCM entry surfaces in a departmental notice 14 months later, with interest.

What to build, in order

Build 1: The live rate engine

This is the highest-ROI thing a mid-size steel trader can build, and it is also the smallest. It is not an ERP. It is a single-purpose internal tool.

What it does: ingests mill circulars (SAIL, JSW, Tata, JSPL, and your regional secondary producers), LME and MCX feeds where relevant, and your landed cost formula — freight, loading, depot margin, customer-tier discount. Pushes a computed sell rate to every salesperson's phone and desk, per grade, per depot, timestamped. When a mill revises, the sheet updates in minutes and old rates are locked. Every quote generated carries the rate version it was priced on, so disputes are resolvable.

What changes once it exists: the 6–18 hour lag collapses to under 30 minutes. Salespeople stop quoting from memory. Owners get a daily report of quotes-vs-realised-margin per salesperson, which is the first time most trading firms can see who is discounting quietly.

What it takes: this is the smallest of the three builds. The scope that moves the number most is how many mill circular formats you need to parse (some are PDFs, some are WhatsApp images, a few now have APIs) and whether you want the tool to just display rates or also generate the quotation PDF the customer receives. Starting with display-only and adding quote generation in a second phase is usually the right call.

What it is bad at: it will not fix a salesperson who wants to undercut. It surfaces the behaviour; the management conversation is still yours to have.

Build 2: Depot stock that matches the yard

This is a legacy modernization problem more than a greenfield software problem. You already have stock data in Tally. The build is the layer that keeps it honest.

What it does: every inward, outward, transfer and cutting loss is entered on a mobile app at the depot, by the person physically handling the material, with a photo and a weighbridge slip attached. The app is offline-first because depot connectivity is unreliable. Weekly, a short physical count on a rotating subset of grades (not a full annual stocktake) reconciles system-to-yard, and variances above a threshold trigger a review before the next dispatch. Transfers between depots create a in-transit bucket that both depots see.

What changes: your salespeople quote against stock they can actually deliver. Partial deliveries and grade substitutions get logged instead of adjusted later. The month-end reconciliation shrinks from a week of arguments to a day of exceptions.

What it takes: more than the rate engine. The scope drivers are the number of depots, whether you have weighbridge integration or manual entry, and how much of your stock is in odd lots (cut pieces, ends, seconds) that need their own handling. Change management at the depot is the harder half of this project — the software is the easier half.

What it is bad at: it does not eliminate shrinkage. It makes shrinkage visible, which is a prerequisite for reducing it but not the same thing.

Build 3: Invoicing that handles GST TDS, RCM and TCS together

This is where a generic ERP will quote you a customization budget roughly 40% above list, per a SIDBI survey cited by Mordor Intelligence, and still not get it right. The rules are specific enough that a purpose-built invoicing layer sitting on top of your existing accounting is usually cheaper and more accurate.

What it does: for every invoice, determines whether the transaction crosses the ₹2.5 lakh scrap TDS threshold, whether the supplier on the corresponding purchase is registered (RCM applicability), and whether TCS applies at the current 2% rate. Generates the invoice, the corresponding GSTR-7 entries, and a monthly compliance pack your CA can file directly. Flags edge cases — mixed-grade invoices, part-scrap-part-prime — for human review instead of guessing.

What changes: your CA stops rebuilding the tax calculation in Excel every month. Departmental notices on RCM shortfalls drop. The audit trail is per-invoice, not per-summary.

What it takes: the scope depends on how many invoice types you run (direct sale, consignment, stock transfer, job work) and whether you want it to file returns directly or hand off to your CA's software. This is not legal or tax advice — your CA and a GST practitioner must sign off on the logic before it goes live, and they should be in the room from week one of the build.

What is not worth building yet

A customer-facing ordering portal. Your customers are calling and WhatsApping because that is how the relationship works. A portal built before the rate engine and stock system are solid will show wrong prices and unavailable stock, and customers will stop using it within a month.

A full CRM. You have three salespeople per depot who know their customers. A CRM before you have quote-vs-margin visibility from the rate engine is a data-entry tax with no return.

An AI demand forecasting model. Interesting, and eventually valuable, but not on a stock base that is 8% wrong. Fix the input data first. AI on top of dirty operational data produces confident wrong answers, which are worse than no answers.

Replacing Tally. Tally works. Your CA knows it. The build sits on top, not underneath.

How to sequence the three builds

Rate engine first, always. It is the smallest, the fastest to show margin impact, and it does not require depot-level change management. Owners see the daily quote-vs-margin report within weeks and the project pays for itself before the next build starts.

Depot stock second. This one needs the rate engine to be live so that the salespeople quoting have a reason to trust the stock number — otherwise they revert to phoning the depot manager anyway.

Invoicing layer third, but with the caveat that if you are already receiving GST notices on RCM or scrap TDS, move it to first. Compliance risk beats margin optimisation.

Running all three in parallel is possible but rarely wise for a firm this size. You have one CFO and one head of IT (or none). Serial delivery with each build proving its value before the next starts is what actually gets finished.

The cost and timeline model

What drives the number on a build like this is not headcount-days at a vendor. It is: how many mill circular formats you ingest, how many depots and how many grades per depot, whether you have any existing digitised stock data or are starting from Tally exports, how many invoice types your business runs, and whether you want to file GST returns directly or hand off to your CA. Two mid-size traders with similar turnover can differ 3x in build cost purely on these variables.

The other driver is change management. A rate engine that nobody uses because the salespeople were not consulted is a sunk cost. Budget explicitly for on-site rollout at each depot, not just software delivery.

To turn a range into a real quote, three specifics matter: the exact number of depots and grades, the current state of your Tally data and whether it is trustworthy enough to migrate, and whether your CA and GST practitioner are available to sign off on the tax logic during the build (not after). A scoping conversation with a team that has built for Indian trading businesses will move faster than one with a general-purpose ERP vendor.

How CodeNicely can help

Two of our engagements map closely to this situation. GimBooks is a YC-backed accounting and GST-invoicing product built for Indian SMBs — the same GST TDS, RCM and TCS calculation logic that a steel trader's invoicing layer needs, hardened over millions of invoices across thousands of businesses. We know where the edge cases hide. Vahak is India's largest logistics marketplace — the depot-to-depot transfer tracking, offline-first mobile apps for yard staff, and reconciliation-under-poor-connectivity problems are the same shape as multi-depot stock for a trading firm.

We build with full IP ownership to the client and no vendor lock-in, which matters when the software is core to how you quote and invoice. If a rate engine or depot stock system is on your near-term list, a scoping call is the fastest way to find out what your specific numbers actually look like. Our work with mid-size Indian businesses is usually where these builds land.

The bottom line

India's finished steel consumption reached 152.13 MT in FY2024-25, up 11.6% year-on-year, and demand is forecast to grow at 9.12% CAGR through 2031. Transaction volumes are compounding. The traders who quote in 20 minutes with stock they can actually ship and invoices that pass audit are taking share from the ones who still work off yesterday's rate sheet. The build order is rate engine, depot stock, invoicing. Everything else can wait.

Frequently Asked Questions

Can I just use a standard ERP like SAP Business One or Oracle NetSuite instead of building custom?

You can, and many mid-size traders do, but the customization to handle intraday mill rate ingestion, depot-level yard reconciliation, and the combined GST TDS + RCM + TCS stack typically runs 40% or more above the base licence, per SIDBI data cited by Mordor Intelligence. And the customized ERP still needs re-customization every time the tax rules change — as they did in October 2024 and again in April 2026. For the three specific problems in this post, a purpose-built layer on top of Tally is usually cheaper and more maintainable.

How long before a rate engine actually shows margin improvement?

The rate engine's impact shows up in the first monthly quote-vs-realised-margin report after go-live, because the tool itself creates the measurement that did not exist before. Whether margin improves in absolute terms depends on how disciplined the sales floor becomes once the data is visible — that is a management question, not a software one. Owners typically see the number they need to have a conversation with their sales team within one to two months of rollout.

What does a build like this typically cost for a mid-size steel trader?

The range is wide because the drivers are specific to your operation: number of depots, number of grades, mill circular formats to ingest, invoice types, and whether existing Tally data is migratable. A single-depot rate engine is a fundamentally different budget from a three-build rollout across eight depots with weighbridge integration. To convert the range into a quote, a vendor needs your depot count, your grade catalogue, a sample of your mill circular sources, and a conversation with your CA on tax logic scope. CodeNicely does not publish a rate card because the honest answer depends on those specifics.

Do I need to replace Tally?

No, and you probably shouldn't. Tally handles your ledger, your CA is fluent in it, and the accounting logic works. The rate engine, depot stock system and invoicing layer sit on top and either push finalised entries into Tally or read stock and master data from it. Replacing Tally is a separate, much larger decision that should be made on its own merits — not bundled into an operational software build.

Who should own this project internally — the CFO, the COO, or IT?

The COO or the owner directly, with the CFO involved for the invoicing build and a nominated depot head involved for the stock build. IT-led builds in trading firms usually fail because the requirements are operational, not technical, and the people who know what the rate sheet needs to look like do not report to IT. If you do not have a COO, the owner runs it and blocks two hours a week for it — less than that and the project drifts.