SE-ERP · Release 2026.1

Start with two modules. Not with a two-year programme.

Most mid-size organisations do not fail at ERP because the software was wrong. They fail because the implementation was scoped as a transformation. SE-ERP is modular by design: deploy finance and procurement now, add projects and assets when you are ready, and keep your customisations through every upgrade.

0Modules, independently deployable
0Typical first go-live
0Functions exposed as API
0Customisations lost on upgrade
Period close: day 3 of 5

The problem

The spreadsheet was never the problem. The eighteen-month plan was.

You already know which processes hurt. What kills the project is a scope that touches every department at once, a customisation layer that cannot be upgraded, and a go-live date that slips until the sponsor changes job.

01

All-or-nothing scope

Finance cannot go live until inventory is configured, which waits on procurement, which waits on a data cleanse. Nothing delivers value until everything does.

02

Customisation as a trap

The workflow you needed was built by modifying the core. Two years later you are three versions behind because upgrading means redoing the modifications.

03

Statutory work bolted on

GST returns, e-invoice IRNs, e-way bills and TDS get handled by an add-on, a consultant's macro, or a person. Every filing season is a scramble.

What it does

Six things a mid-size ERP has to get right.

01 · Finance

A close that finishes on the fifth working day

General ledger with multi-entity and multi-currency books, receivables and payables, bank reconciliation with statement import, and cost centre allocation. The close checklist is a first-class feature: it shows exactly which task is blocking, who owns it, and what the dependency is — rather than a controller chasing four people over email.

  • Multi-entity, multi-currency GL with inter-company entries
  • Receivables ageing, dunning and credit limits
  • Bank statement import with rule-based auto-matching
  • Close checklist with owners, blockers and audit trail
Diagram: a shared core of identity, ledger, documents and events with nine modules docking onto it, showing that a deployment can begin with two.
Modular architecture · start with two, add the rest later
02 · Statutory

Indian compliance as a core feature, not an add-on

GST-ready invoicing with HSN and SAC on every line, e-invoice IRN generation and e-way bill hooks through a GSP, reverse charge handling, TDS deduction and certificates, and GSTR-1 and GSTR-3B data extracts that reconcile against your books before you file rather than after a notice arrives.

  • e-invoice IRN and e-way bill via your chosen GSP
  • HSN/SAC, place of supply and reverse charge handled at line level
  • TDS deduction, challan tracking and Form 16A data
  • GSTR-1 and 3B extracts with pre-filing reconciliation

Boundary: we produce the data and the reconciliations. We are not your tax advisor and we do not sign off a return — your chartered accountant does, and the system is built so they can verify rather than trust it.

03 · Procure to pay

Three-way match, without the chasing

Requisition, approval, purchase order, goods receipt, invoice — with the three-way match enforced rather than reconstructed. Vendors get a portal to submit invoices and track payment status, which removes most of the phone calls your accounts team currently fields.

  • Requisition and PO approval chains by value and category
  • Vendor portal for invoice submission and payment status
  • Enforced three-way match with tolerance rules
  • Landed cost allocation across freight, duty and insurance
Diagram: the procure-to-pay flow as a state machine from requisition through approval, purchase order, goods receipt and three-way match to payment.
Procure to pay · approval gates and the three-way match
04 · Inventory & assets

Stock you can trust, assets you can find

Multi-warehouse stock with batch and serial tracking, reorder points and cycle counting. Asset registers carry warranty, service history and spares consumption — which is how a camera estate or a display fleet stops being a spreadsheet that nobody has updated since commissioning.

  • Multi-warehouse and bin-level stock with transfers
  • Batch, serial and expiry tracking with traceability reports
  • Asset register with warranty, service history and depreciation
  • Preventive maintenance schedules with spares reservation
05 · Projects & field service

Where the work actually happens

Project budgets against actuals, timesheets that feed both billing and payroll inputs, work orders dispatched to a technician's phone, and spares consumption booked back to the asset and the job. For a services business this is the module that decides whether you know your margin per project before the year ends.

  • Project budget, commitment and actual in one view
  • Timesheets with approval, feeding billing and payroll inputs
  • Technician mobile app with offline capture
  • Spares and labour costed back to job and asset
06 · Platform & controls

Customise without forking

Every function is a documented REST or GraphQL endpoint, and workflow extensions attach through scripting hooks rather than modifications to the core. That is the mechanism that keeps your customisations through upgrades — they are extensions with a contract, not edits to our source. Controls are standard: SSO, granular roles, maker-checker approvals and a field-level audit log.

  • REST and GraphQL API for every function, with OpenAPI specs
  • Scripting hooks and webhook events for custom workflow
  • Staging sandbox that mirrors production data structures
  • SSO via SAML or OIDC, granular RBAC, maker-checker, field-level audit

Module explorer

Pick the two you need first.

Each module is independently deployable against the shared core. The most common starting pair is Finance plus Procurement.

Finance

The module almost everyone starts with, because it is where the pain is measurable. Ledger, receivables, payables, banking and statutory output, with the period close instrumented so you can see it shortening month over month.

Core

General ledger

Multi-entity, multi-currency, inter-company.

AR

Receivables

Ageing, dunning, credit limits, collections.

AP

Payables

Invoice capture, approval, payment runs.

Stat

GST & TDS

IRN, e-way bill, GSTR extracts, challans.

Specifications

The page your CFO and IT lead read together.

Modules & scope
Finance
General ledger, receivables, payables, banking, cost centres, period close, statutory output
Procurement
Requisitions, approval chains, purchase orders, goods receipt, vendor portal, three-way match
Inventory
Multi-warehouse, bin level, batch and serial, expiry, cycle counting, landed cost
Projects
Budget and actual, milestone billing, timesheets, resource allocation
Assets & field
Asset register, depreciation, preventive maintenance, work orders, technician mobile app
People
Employee master, leave and attendance, expense claims, payroll inputs — not a payroll engine
Analytics
Role dashboards with drill-down, report builder, warehouse export, threshold alerts
Platform & APIs
API
REST and GraphQL for every function, documented with OpenAPI; sandbox credentials provided
Extensibility
Scripting hooks and webhook events; extensions have a versioned contract and survive upgrades
Data tooling
Bulk import with validation and dry-run, incremental export, migration templates
Environments
Production plus a staging sandbox mirroring production structures
Upgrade path
Quarterly releases; extensions tested against the release candidate before you upgrade
Statutory & compliance
GST
HSN/SAC at line level, place of supply, reverse charge, e-invoice IRN and e-way bill via GSP
Returns data
GSTR-1 and GSTR-3B extracts with pre-filing reconciliation against 2A/2B
TDS
Section-wise deduction, challan tracking, Form 16A source data
Books
Multi-entity, multi-currency, financial year handling, audit trail retention
Not included
Statutory audit sign-off and tax advisory — your chartered accountant's role, not ours
Security & controls
Authentication
SAML 2.0 or OIDC; MFA enforced through your identity provider
Authorisation
Granular RBAC by module, entity, cost centre and record type
Segregation of duties
Maker-checker enforced in the platform, including on API calls
Audit
Field-level change log with actor, timestamp and previous value; append-only
Encryption
TLS in transit, encrypted at rest; document store encrypted separately
Performance & limits
Database
PostgreSQL; read replicas for reporting workloads
Tested scale
Up to 500 named users and a few million transaction lines per year per entity
Honest ceiling
Not built for tens of thousands of users or high-frequency retail POS volumes — say so early and we will tell you if you are outside the envelope
Reporting
Heavy reports run against replicas so a month-end query does not slow transactions
Deployment, licensing & support
Deployment
Cloud (managed by us), your cloud tenancy, or on-premise; containerised
Data ownership
Yours, with full export in open formats on exit — including a documented schema
Licensing
Per named user by module tier, annual subscription including support
Implementation
Fixed-scope per module — see integration and migration services
Support
Standard included; Enhanced recommended for multi-entity — see support tiers

Interoperability

Systems we already speak to.

Naming a system states interoperability, not partnership or endorsement.

TallyLedger import GSPe-invoice · e-way Banking filesRecon · payments Payment gatewaysCollections Payroll providersInput handoff SAML / OIDCIdentity PostgreSQLDatabase S3-compatibleDocuments BI toolsWarehouse export WebhooksEvent consumers Biometric devicesAttendance PrometheusMetrics

Deployment

Three ways to run it.

Managed cloud

We run it, patch it and back it up. The default for organisations without a platform team.

  • Fastest to first go-live
  • Backups and DR drills included
  • Region-pinned data storage

Your cloud tenancy

Deployed into your account under your controls, with our Helm charts and runbooks.

  • Your security and network policy
  • Your cloud commitment and billing
  • We retain upgrade responsibility

On-premise

For organisations with a data-locality mandate. Fully supported, including air-gapped.

  • No outbound dependency
  • Source escrow available
  • Offline release bundles
0First module liveDiscovery to production, fixed scope
0Target period closeWorking days after period end
0Modules on one coreAdded without re-implementation
0Extensions broken by upgradeTested against each release candidate

Before you ask

The questions that decide the deal.

Why choose this over SAP Business One, Odoo or Zoho?

Straight answer: often you should not. If you want the largest partner ecosystem and a product that will outlive any single supplier, buy SAP Business One. If you want the cheapest entry point and a huge module marketplace, Odoo is hard to beat. If your processes are standard and you want it working next month, Zoho will do it. Choose us when you need real customisation that survives upgrades, when your operations are unusual enough that standard modules fight you, or when you want the same team that runs your FIDS or camera platform to own the business systems too. If none of those apply, we will tell you.

What is a realistic implementation timeline?

Twelve weeks to a first module in production on a fixed scope, assuming your master data is available and someone on your side owns decisions. A second module typically adds six to eight weeks. Anyone promising a full multi-module ERP in six weeks is either not migrating your data or not testing. The long pole is almost always data cleansing, and we quote it separately so it stays visible instead of hiding inside a fixed price.

How do customisations survive upgrades?

Because they are extensions, not modifications. Custom workflow attaches through scripting hooks and webhook events with a versioned contract, and custom fields and reports are configuration rather than schema edits. Before each quarterly release we run your extensions against the release candidate in your sandbox and fix breakage on our side. We do not fork the core for a customer, and if a requirement genuinely needs a core change we build it as a product feature or decline it.

Who owns the data, and what happens if we leave?

You own it. On exit you get a full export in open formats — CSV plus a documented PostgreSQL schema dump — including documents from the object store, at no charge. We would rather you leave cleanly than stay because extraction is painful. Source escrow is available for on-premise deployments so a supplier failure does not become an operational crisis.

Can you handle our statutory filings?

We produce the data and the reconciliations, and we generate IRNs and e-way bills through your GSP. We do not file on your behalf, we do not sign off a statutory audit, and we are not your tax advisor. Your chartered accountant remains in that role — the system is designed so they can verify the numbers against source documents rather than take them on trust.

What is SE-ERP not built for?

High-frequency retail point-of-sale volumes, tens of thousands of concurrent users, and heavily regulated manufacturing process control. It is tested to around 500 named users and a few million transaction lines per entity per year. If you are beyond that, a tier-one ERP is the right answer and we will say so in the first call rather than discovering it during a performance test.