GST-ready books, multi-warehouse stock and a full admin console for accounting teams, contractors and traders who have outgrown a spreadsheet — as a desktop app, or straight in the browser.
Accounting Software · GST Compliance · Construction & Trading
Based in
Nagpur, Maharashtra, India
Built
2026
Timeline
Actively developed through 2026 · live in production, updated continuously on a live server
Scope
Product design & build · GST compliance · Desktop app packaging · Web platform · Windows compatibility · Ongoing support
The problem
A tool that works for one accountant on one machine does not work for a multi-company business with a GST filing deadline.
Accsys had to be more than a single-user ledger: multi-company and multi-financial-year support from the schema up, GST compliance that matches how Indian accounting teams actually file, and a way to hand it to a client who is not going to open a terminal.
The harder constraint was distribution: some clients want an installable desktop app with a proper installer experience; others are still on Windows 7 machines that cannot run a modern Python build; others would rather not install anything at all. The same product had to reach all three — a desktop app, a Win7-compatible legacy build, and a browser-based deployment — from one codebase.
Multi-company, multi-financial-year from the start
Every voucher, report and master record had to be scoped to a company and a financial year — not bolted on after a single-tenant schema was already in production.
GST compliance, not just bookkeeping
Reverse charge (RCM), CGST/SGST/IGST splits, GST returns export and HSN-coded items had to work the way an Indian accounting team actually files, not as a generic "tax field".
A contractor and trading vertical, not just retail
Sub-contractor bills, construction purchase bills and transportation bills needed their own schema — a generic purchase bill was not going to cover how contracting businesses actually get billed.
Two Windows generations, one app
Some clients are still on Windows 7 machines; others run current Windows. The same product had to install and run properly on both, from one codebase.
Non-technical, self-managed operation
Clients run and manage their own database rather than a cloud service we control, so every update we ship has to be something their own IT person can apply safely, without breaking existing data.
What we built
5 modules, one shared system
Enter it once. Every report, screen and module that needs it already has it.
GST-compliant vouchers, RCM and contractor billing
17 voucher types behind one posting path — from everyday receipts and payments to GST reverse charge and the contractor-specific bills a generic accounting package does not have.
10 voucher types, one posting path: Receipt, Payment, Journal, Sub-Contractor Bill, Transportation Bill, Construction Purchase Bill, Bill Wise Receipt, Cheque Return, RCM Voucher, Bank Book Updation.
RCM voucher handles GST self-invoicing — no side spreadsheet needed.
Sub-contractor and construction bills built for how contractors actually invoice.
Sales invoicing, purchase bills and GST-ready documents
Sales invoices, returns, credit and debit notes on the sell side; purchase bills, invoices and returns on the buy side — every line computing its own GST from the item master, not the operator’s memory.
Financial reports, GST returns and live dashboards
Ten accounting report types, full sales/purchase/inventory report families, a GST export for return filing, and an Executive Dashboard — all reading from the same postings every voucher screen writes.
Ten reports: Cash Book, Bank Book, Trial Balance, Balance Sheet, P&L, Receipts & Disbursements, Ledger Book, Sub-Ledger Statement, Receivable & Payable by Party.
Full report families for Sales, Purchase and Inventory too.
Inventory Reports update the instant a sale or purchase posts.
Goods Receipt, Goods Issue, Stock Transfer, Physical Stock and Opening Stock — every movement checked against the same available-stock function, so no two screens can disagree about what’s on the shelf.
Goods Receipt, Goods Issue, Stock Transfer, Physical Stock, Opening Stock — the full lifecycle, multi-warehouse.
One shared stock record — a sale moves it, just like a receipt does.
Same stock check everywhere, whether it’s Inventory, Sales or Purchase.
Multi-company setup, masters and the admin console
Companies, financial years, twelve master-data screens, user permissions and opening-balance migration — the layer that lets a super-user onboard a new business without a developer on call.
Companies and Financial Years set the scope everything else inherits.
12 master-data screens: accounts, partners, items, warehouses and more.
Users and permissions match everywhere — menu and access, always in sync.
No install at all, if you’d rather not. Same data, same permissions, same everything.
One-click launcher, opens the browser automatically.
Same version online and on a client’s own server.
Desktop and browser talk to the server identically.
Live updates roll out automatically — no separate builds to track.
How it was built
Dependency order, shipped continuously
We built the foundations first — company and financial-year separation enforced from the ground up — then layered vouchers, reporting, inventory and the admin tools on top, packaging for two Windows generations and a live web version as the product grew.
Phase 1
Foundations: company and year-based access
The core structure and secure sign-in came first, with every company and financial year kept properly separate from day one — every voucher and report built after this point inherits that separation automatically.
Phase 2
Core vouchers and the ledger
Receipt, payment and journal vouchers, all posting into one shared ledger, with a consistent pattern established here and reused for every voucher type that followed.
Phase 3
GST compliance and the contractor vertical
RCM vouchers, sub-contractor bills, construction purchase bills and transportation bills — the piece that makes Accsys fit a contracting or trading business rather than a generic ledger.
Phase 4
Sales, purchase and reporting
Invoicing, GST-ready documents, and the full family of reports — Trial Balance through GST Export — all reading from the same entries every voucher screen writes.
Phase 5
Inventory and the admin tools
Multi-warehouse stock movements with a live stock check on every transaction, plus the settings, permissions and company/year setup an owner can manage without calling a developer.
Phase 6
Packaging and deployment
A desktop app you install, a compatibility build for older Windows 7 machines, and a version that runs entirely in the browser — with the live version updated automatically whenever we ship a change.
Architecture
One database, one deployment, one payment path
One shared system with company and financial-year access checked centrally, a fast, modern interface talking to a single backend, and two ways to run the exact same build — installed as a desktop app, or served as a website. No separate mobile version, no second set of permissions to keep in sync.
Interface
Fast, modern interface
Live charts & dashboards
44 screens, one consistent design
Every screen — vouchers, masters, reports, utilities — is built from the same shared design, so the whole product feels like one thing rather than forty separate tools.
Backend
One secure system
Consistent processing for every module
Every part connected
Each module has its own consistent way of handling data and posting to the books, kept simple and predictable rather than one-off per screen.
Data
One shared database
61 linked records
Every entry traceable
Every transaction is recorded with full detail, and the books update automatically the moment anything is posted.
Sign-in & access
Secure sessions
Company & year scoping
Role-based permissions
Every request is checked against the company and financial year you’re actually signed into, so nobody sees or affects data they shouldn’t.
Desktop packaging
Native desktop app
Installer builds
Windows 7-compatible build
Two installer builds — one for current Windows, one for older Windows 7 machines — from the exact same underlying application.
Live hosting
Cloud hosting
Automatic deployments
Zero-downtime updates
Updates ship straight to the live, hosted version the moment they’re ready — no manual deployment step.
The chart of accounts — the structure every voucher, report and stock movement ultimately connects back to.
Engineering decisions
The six calls that shaped the build
Every one of these was a fork where the fast answer and the right answer differed. They are the reason the platform could keep absorbing modules without collapsing under them.
01
Company and financial-year access is checked once, everywhere
A new voucher type or report is correctly isolated to its own company and year by default — there’s no screen where that check can be skipped or gotten wrong.
The problem
In a system where every company can run multiple financial years, it would be easy for one screen to forget a scoping check and let one company’s data leak into another’s report.
What we did
Every request is checked centrally against the company and financial year the person is actually signed into, falling back to sensible defaults and refusing anything that doesn’t match — rather than trusting each individual screen to remember the check.
02
One combined data load instead of dozens of small ones
Opening a voucher screen is instant after the first load of the day, and the server handles one combined request instead of a burst of small ones every time someone opens a form.
The problem
A voucher form needs half a dozen dropdowns — accounts, business partners, items, warehouses. Loading each one separately, every time a screen opens, makes the app feel slow and puts unnecessary load on the server.
What we did
Everything a session needs is fetched once, in a single request, and kept ready on the user’s device for about a minute before it refreshes.
03
Fast lists that never go fully broken
List screens stay fast as data grows, and the fallback means a screen is never fully broken — only briefly slower, while things catch up.
The problem
Voucher lists and counts — the screens accountants live in all day — are the first thing to slow down as a company’s transaction history grows.
What we did
The busiest list and report queries run through a faster path by default, with an automatic, reliable fallback if that faster path isn’t ready.
04
The desktop app and the online version always talk to the server the same way
A whole category of "works for us, broken for the client" bugs simply can’t happen, because there is exactly one correct way to reach the server.
The problem
An installed desktop app doesn’t always run at the address you’d expect — a shortcut based on where the app happens to be running can work perfectly in testing and quietly fail once it’s actually installed on a client’s machine.
What we did
Every request to the server goes through one, single, explicitly defined path — documented as a firm rule, not something left for each new feature to figure out on its own.
05
Updates that are safe to apply twice, because clients manage their own data
Clients can apply an update from written instructions on their own schedule, and applying one twice by accident never corrupts data that’s already there.
The problem
Accsys is not a hosted service we control — each client runs and manages their own database. An update that assumes it only ever runs once, on a database we control, isn’t safe here.
What we did
Every update we ship is written so it’s safe to apply more than once, and documented clearly enough that a client’s own IT person can apply it, check it worked, and move on — without a support call.
06
One stock record behind sales, purchase and inventory — not three
A warehouse’s available stock is one single number, accurate the instant an invoice is posted — not something reconciled between three separate modules at month end.
The problem
Sales, purchasing and warehouse operations are usually built as separate systems that each keep their own idea of "how much stock is there," and reconciling the three becomes a manual, monthly exercise.
What we did
Every document that affects stock — a sale, a purchase, a receipt, an issue, an opening balance — updates the exact same shared stock record. A sale that would oversell a warehouse is rejected the moment it’s attempted, not caught later.
07
One consistent look and feel, enforced everywhere
A new master-data screen is quick to add rather than a rebuild, and the accounting reports, the inventory reports and the admin screens all look and feel like one product.
The problem
Forty-plus screens — vouchers, masters, reports, utilities — built independently drift into inconsistency fast: different table styles, different buttons, different empty states from screen to screen.
What we did
A single, fixed design is the only way any screen gets built, and simple lookup screens are all built from one reusable pattern rather than as one-off work each time.
The product
Screens from the live platform
Taken from production and from the admin console built alongside it. Click any shot to enlarge — each module page carries the rest.
The Executive Dashboard — the numbers ownership actually looks at, on login.The RCM voucher — GST reverse charge as a first-class entry, not a manual workaround.A GST sales invoice, with tax computed automatically from the item’s own rate and code.Goods Receipt — stock checked live against what’s actually on hand, the same way every screen does it.Trial Balance, drawn straight from the same records every voucher screen writes to.Switching company and financial year — the scope every later screen inherits.
Outcome
What the client ended up with
Live, running real books
Runs in production today — updated the moment we ship a change.
One app, two Windows generations
Current Windows and Windows 7, both from the exact same app.
GST-compliant by construction
Reverse charge, CGST/SGST/IGST, GST export — all from the same books.
Built for contractors, not just retail
Sub-contractor, construction and transportation bills, built to fit.
Runs on a client’s own systems
Self-hosted, updates a client’s own IT can apply safely.
A consistent product, not forty bespoke screens
One shared design. A new screen is quick to add, not a rebuild.
Multi-company & multi-year
GST compliance
Multi-warehouse inventory
Desktop & web access
Role-based permissions
Self-hosted database
Handover
Delivered means you can run it without us
Delivered means a client can install it, connect their own database, and run their books — no developer on call.
Two installers, ready to hand to IT
Current Windows and Windows 7, both fully self-contained.
A one-time setup wizard
Walks a non-technical user through connecting their database.
A running log of every update
Every data-affecting change, in order, with a way to check it worked.
A documented way to update the live version
Rebuilt and redeployed from clear, written steps.
A repository the client owns
Code and setup scripts, with build instructions included.
Investment
What a build like this costs
Fixed scope, fixed timeline, agreed before a line of code is written — the same model whether it is a single voucher screen or a full multi-company platform.
Single-module tool
One voucher type, one report family, or one admin screen added to an existing system. Typically 2–4 weeks.
Full accounting platform
Something the size of Accsys: multi-company, multi-financial-year, GST-compliant, with desktop packaging and a live web deployment. Typically 10–16 weeks.
Continuing work
A monthly retainer for new voucher types, report families or integrations after go-live, or a clean handover with documentation if you would rather run it in-house. Both are normal.
Tell us the scope and we will send a fixed price and a date within two working days.
NOT READY TO BOOK A CALL?
Get the multi-company go-live checklist we use for every rollout
Every accounting system rollout has the same failure points — opening balances that don’t net, GST accounts pointed at the wrong ledger, a financial year closed before reconciliation. This is the checklist we run before any company goes live on Accsys.
Opening-balance reconciliation, G/L and sub-ledgers
GST account mapping, before the first invoice
Financial-year rollover and numbering checks
Permissions, set before logins go out
FAQ
Questions people ask about this build
Is Accsys a client project or your own product?
Our own. We built Accsys as a self-initiated product rather than for one commissioning client, which is why this page does not carry a third-party testimonial — everything else on it, the architecture, the live deployment, the screenshots, is real.
Is it actually live?
Yes. Accsys runs in production on a live server, updated automatically the moment we ship a change. The screenshots on this page are taken from that build.
Does it handle Indian GST correctly?
It handles the mechanics an Indian accounting team needs day to day: CGST/SGST/IGST splits resolved from the company’s own configured accounts, reverse charge (RCM) as a dedicated voucher type, HSN-coded items, and a GST-ready export for return filing. We are not a chartered accountancy and this is not filing advice — it is the software layer underneath a real filing process.
Can it run without an internet connection?
Yes — that is the point of the desktop build. The installed app, with its own local database, runs entirely offline. The web version is the exact same system, just reached over the internet, for clients who would rather not install anything.
Who owns the code if we commission something like this?
You would. Application code and setup scripts live in a repository you own, the same way we structured this one, with a running change log and update process documented alongside it.
Do you build accounting or ERP software for other industries?
Yes. The pattern here — one shared system, properly separated company by company, a safe update process for a self-hosted database, and packaging for however your users actually work — is how we would approach inventory, billing or ERP software in any industry, not just accounting.
Who built this
Senior engineering, not an account manager
SigmaticAI is led by Ketan Khamgaonkar — an IIT Roorkee M.Tech who went on to PhD research at IIT Bombay before spending four years building AI automation, agentic systems and full web and mobile products. On every project you talk to the person writing the code.
No pitch deck. Tell us what you are trying to ship and we will tell you the fastest honest path to live — including if that path is smaller than you thought.