Skip to content
PRS India

Custom ERP and operations systems

ERP Development

ERP systems built on a stock and money ledger that is only added to, never changed — multi-plant, multi-GSTIN, correct for GST, and matched to the physical count instead of arguing with it.

Last updated

  • Append-only stock ledger — stock at any past date, and an audit trail on every unit
  • Multi-plant, multi-warehouse and multi-GSTIN from the first migration
  • GST-correct: HSN, place of supply, e-invoice IRN, e-way bills, GSTR-1 that ties out
  • Migration from Tally and spreadsheets with a reconciled parallel run
What this is

One number, and everyone believes it.

Almost every ERP conversation we have starts in the same place: a Tally setup that only handles the books, four Google Sheets that hold the real day-to-day facts, and one person — usually in accounts — who is the only one who knows how the numbers connect. When that person takes leave, the month-end closes late.

An ERP is not accounting software. It is the one place that records what you have, what you owe, what you are owed, and where every order stands right now. Get it right and a plant manager in Bhiwadi and a finance controller in Gurugram see the same number at the same moment. Get it wrong and you have bought a very expensive data-entry job.

We build ERPs for manufacturers, distributors and multi-location retailers who have outgrown spreadsheets but do not fit a ready-made product — because their costing is job-based, or they run three GSTINs across two states, or they make goods to order and no template has a field for it. We will also tell you, honestly, when Odoo or Zoho would do the job for a fifth of the money.

Sound familiar

You do not have an ERP. You have a person.

These are the messages that reach our inbox. Not one of them is solved by another spreadsheet.

  • The system stock and the physical count never agree

    A quantity column that six processes overwrite, and a warehouse manager who "corrects" it by hand when it looks wrong. Nobody can find out why the number moved.

  • Month-end takes eleven days

    Purchase registers in one sheet, sales in another, Tally somewhere in the middle. Closing the books is a matching project, not a report you run.

  • One person understands the whole thing

    They built the macros, they know which column is authoritative, and they have not taken a proper holiday since 2021. That is not a good system, it is one weak spot that can break everything.

  • Anyone can edit anything, retroactively

    A six-week-old challan gets edited to fix a typo and today's stock silently shifts by 40 units. No record of who changed it, no approval, no way to prove what the number was on the 31st.

  • You cost jobs after they are finished

    The true material and labour cost of an order shows up weeks later, once someone adds it up by hand — long after you quoted the next one at the same price.

  • Each plant has invented its own process

    Three units, three GRN formats, two GSTINs and a stock transfer note that exists only in WhatsApp. Combined reports are guesswork put together once a quarter.

The one decision that makes an ERP trustworthy.

Here is the single design decision that separates an ERP you can trust from one you cannot: stock must be an append-only ledger, never a mutable quantity column.

The easy design is a products table with a qty integer that every process increments and decrements. It works for a month. Then two users receive the same GRN at the same time and one save silently overwrites the other. Then somebody edits a six-week-old delivery challan to fix a typo and today's stock quietly shifts by 40 units. Then a warehouse manager "corrects" the number by hand because it looked wrong, and now nobody can find out why. You end up with a figure nobody believes and a physical count every two weeks.

We save stock as movements that never change: every receipt, issue, transfer, adjustment and return is a row that is written once and never updated. Current stock is the sum of those rows. Nothing edits history — a mistake is fixed by a reversing entry, just like in a journal. That gives you three things you cannot buy back later: stock on any past date, a record that names the person and the time behind every unit, and a number that matches your physical count instead of arguing with it.

The same rule applies to money entries, batch and serial tracking, and costing. Add, never change. It is not exciting, but it is the whole game.

What changes

What a real system of record is worth.

Typical change across manufacturing and distribution rollouts, measured two quarters after the cut-off date — not on the day it goes live, when everyone is still being polite.

Scope an ERP
2days
Month-end close

Down from nine to eleven days

99.2%
Stock accuracy

System vs physical count, cycle-counted

0
Retroactive edits

Corrections are reversing entries, not overwrites

18hrs/wk
Data entry eliminated

Duplicate keying across sheets and Tally

How we roll it out

Module by module. Nothing goes live on faith.

Switching everything on one day, on a system this central, is how ERPs make the news. We do it in small parts, each one in real use before the next begins.

  1. 01

    Process mapping on the floor

    2–3 weeks

    We walk the plant and the warehouse. We watch a GRN actually get received, a challan actually get raised, a job card actually get filled. What people do and what the SOP says are different things, and the ERP has to serve the first one. We leave with a process map, a data plan and an honest list of the habits that will have to change.

  2. 02

    Ledger and master data design

    2–3 weeks

    Chart of accounts, item masters, HSN codes, tax classes, units of measure, warehouses, entities and GSTINs. Then the movement ledger itself. This is the plain two weeks that decide whether the system still works in year four, and we do not rush it to make a plan chart look better.

  3. 03

    Core modules: purchase, stock, sales, GST

    8–12 weeks

    Each module goes into real use as soon as it is ready. Purchase orders, GRN with quality hold, stock movements and transfers, sales orders, delivery challans, GST-correct invoicing with IRN and e-way bill. Your buying team is using the purchase module while we are still building production.

  4. 04

    Migration and parallel run

    4–6 weeks

    Masters, opening balances and history are pulled from Tally and the spreadsheets, cleaned of duplicates, and loaded as opening ledger entries. Then both systems run side by side for a full cycle, matched every single day. Trust in the new number comes from watching it agree with the old one, not from being told to trust it.

  5. 05

    The cut-off, and holding it

    1 week

    A fixed date after which the old sheet is read-only, announced by someone senior enough that it sticks. Every process owner confirms that their module is live. We stay on the floor for the first week, because on day two somebody will want to go back and someone has to be there to say no and then help.

  6. 06

    Costing, production and reporting

    8–16 weeks

    Bills of material, job cards, work-in-progress, actual job costing, quality checks, and the dashboards a controller really opens. Built on a ledger that is already trusted, which is the only reason these numbers mean anything.

What you get

The modules that carry the business.

Built on one ledger, one set of master data, one permission model. Not six products joined together with a nightly CSV.

Inventory on a movement ledger

Many warehouses, batch and serial tracking, bin locations, regular counting, and stock as at any past date. Corrections are reversing entries — history is never rewritten.

Procure to pay

Indents, RFQs, purchase orders with approval limits, GRN with a quality hold, three-way matching against the invoice, and vendor ageing that finance can act on.

Order to cash

Quotations, sales orders, stock set aside from what is really available, delivery challans, e-invoice and e-way bill, receivables ageing and a credit limit that blocks the order instead of only warning.

Production and job costing

Multi-level bills of material, work orders, WIP tracking, machine and labour records, scrap and rework. Actual cost per job, visible while the job is still open.

Role-based access and maker-checker

Permissions set by entity, plant and module. Money entries and rate changes go through an approval trail that names the person, the time and the value before and after.

Reporting people actually open

Stock ageing, margin by SKU and by customer, plant-wise consumption, receivables and payables ageing. Combined across GSTINs, and you can open it down to each single movement.

The build-or-buy call

We will talk you out of this if we should.

  Tally + sheets Zoho / Odoo Custom ERP
Real-time stock across plants No Yes Yes
Append-only auditable ledger No Partial Yes
Job-based or make-to-order costing No Painful Native
Multi-entity, multi-GSTIN consolidation Manual Add-on Native
Cost scales with headcount No Per user, forever No
Time to first live module No 6–10 weeks 10–14 weeks
Sensible when Under ₹5 cr turnover Conventional processes Your process is the moat
Change management

The ERP does not fail in the code. It fails on the floor.

ERP rollouts do not usually fail for technical reasons. They fail because the store supervisor keeps a second notebook, the sales team keeps quoting from an old price list, and nobody senior ever said out loud that the spreadsheet is now dead.

So we plan the people half as carefully as the data design. We name an owner for each module — a real person, not a committee. We run the new system next to the old one for one full cycle, matching daily, so trust is earned and not ordered. We train on your data, not on demo data, because a warehouse team will not care about a made-up example. And we agree a cut-off date after which the old spreadsheet is read-only, and we keep to that date.

We have seen more ERPs die from a cut-off that nobody enforced than from any bug we have ever shipped.

  • A named process owner per module — a person, not a committee
  • One full cycle of parallel running, reconciled daily
  • Training on your data, never on demo data
  • A hard cut-off date, announced by someone senior enough that it holds
The stack

Built to be maintained by people you can hire.

No private runtime, no per-seat licence, no vendor who can hold your operations hostage at renewal.

Laravel 12
PHP 8.3
PostgreSQL
Redis
Laravel Horizon
FAQ

What boards ask before they sign off an ERP.

Still have a question?

Often, yes — and we will say so. If your ways of working are common and you are willing to change how you work to match the product, a ready-made ERP is cheaper and faster. Building makes sense when the product truly does not fit: job-based costing it cannot do, a make-to-order flow with no field for it, or licence costs that grow with the number of staff, which you plan to double. We do that comparison in discovery, in writing, before anyone commits.

Yes, and old history is exactly the part people underestimate. We pull out masters, opening balances and past transactions using Tally XML or ODBC. We clean the duplicates — you will have three spellings of the same supplier — and load them as opening ledger entries, not as a balance that can be changed. Tally usually stays as the official books for a full cycle while the ERP runs next to it, matched every day, until the two agree without hand work.

It changes how the data is set up, so it must be decided on day one and not added later. Each legal entity gets its own GSTIN, its own books and its own invoice series; stock transfers between them are real transactions with tax effects, not just a move in the warehouse. Users can see only the plants they belong to. Combined reports add up across all entities. Adding this later means rewriting the ledger, which is why we ask about it in the first meeting.

A focused core — inventory, purchase, sales, GST invoicing and basic finance for one entity — takes 16 to 22 weeks to reach a live parallel run. Add production, job costing, multi-plant and quality and it is 30 to 45 weeks. We deliver one module at a time and put each one into real use as soon as it is ready. So you get value from purchase and stock while production is still being built. Anyone quoting a full ERP in eight weeks is quoting a demo.

People and habits, almost always. The store supervisor keeps a parallel register. Sales keeps quoting from the old price list. Nobody senior ever declared the spreadsheet dead. We plan for this: a named owner for each module, one full cycle of running both systems side by side with daily matching, training on your real data and not demo data, and a firm cut-off date after which the old sheet becomes read-only. The technical risk is small. Getting people to change is the real project.

Yes, built in. Tax is worked out from the HSN code and place of supply. So a sale inside the state splits into CGST and SGST, and a sale to another state becomes IGST, without anyone having to decide. Above the turnover limit we send invoices to the IRP for the IRN and QR code, and make e-way bills for goods above the value limit. Credit notes are raised against the original invoice, so your sales register and your GSTR-1 match without a spreadsheet job every two weeks.

Send us the stock figure nobody in the building believes.

Bring the Tally export, the four spreadsheets and the last physical count. We will show you exactly where the number goes wrong and what it takes to make it right.

Let's talk erp development

Bring us the hard version of the problem.

A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.