MSME Invoice Acceptance and Delayed-Payment Interest Ledger (MSMED Act 45-Day Rule)

Micro and small enterprises in India wait far too long to be paid. The MSMED Act, 2006 gives them statutory weapons — section 15 requires buyers to pay within an agreed period not exceeding 45 days from acceptance, and section 16 makes late buyers liable to compound interest with monthly rests at three times the RBI-notified bank rate — yet an individual supplier still tracks invoices in Excel, computes interest by hand and argues over tampered-looking printouts when a dispute reaches the MSEFC (filed through the MSME Samadhaan / MSME ODR portals).

This project builds a tamper-evident invoice and payment-event ledger in Node.js for that fight. Every business event — invoice issued, delivery, objection, acceptance (actual or deemed), payment, dispute, MSEFC referral — is appended with a SHA-256 hash chained to the previous event, so any later edit breaks the chain and the verifier flags it. A daily anchor root hash, exported and preserved outside the system (printed register, e-mail, or a public service), proves the ledger state existed on a given day. A statutory-clock module implements deemed acceptance (the 15-day written-objection window), the 45-day due date and the section 16 interest calculation; a dispute state machine mirrors the Samadhaan workflow; and a React dashboard shows ageing, interest statements, defaulter rankings and chain-integrity status.

No cryptocurrency, tokens or consensus network are involved — the ledger borrows blockchain's tamper-evidence without pretending two parties will run nodes. The stack is IGNOU-approved and the design stores no government ID numbers.

When a micro or small supplier chases a delayed payment, three things repeatedly go wrong. First, the record-keeping: invoices, delivery proofs and payment entries live in editable spreadsheets, so the buyer can allege manipulation and the supplier cannot prove otherwise. Second, the arithmetic: deemed acceptance (the 15-day written-objection rule), the 45-day due date and section 16's compound interest with monthly rests at three times the RBI bank rate are consistently miscalculated by hand, weakening legitimate claims. Third, the escalation path: the MSME Samadhaan/ODR workflow has clear stages — application, buyer response, MSEFC conciliation, arbitration — but the supplier has no tool that tracks an invoice through those states. What is needed is a small, verifiable system in which every invoice event is appended to a hash-linked ledger that any later tampering would break, the statutory clock and interest are computed automatically and reproducibly, and disputes are tracked as first-class states all the way to MSEFC referral.

Abstract

Delayed payments are the single biggest working-capital complaint of Indian MSMEs. The MSMED Act, 2006 answers them with a 45-day payment rule (section 15), compound interest with monthly rests at three times the bank rate (section 16) and a facilitation-council remedy (section 18) now filed online through the MSME Samadhaan portal, with new applications moving to the MSME ODR portal. But when a supplier reaches that forum, the evidence is usually a set of Excel sheets and e-mails that a buyer can easily contest. This project delivers a Node.js event ledger that records every invoice, acceptance and payment as a hash-linked, append-only event, automates the statutory clock and interest computation, and exports court-ready statements — making the supplier's record tamper-evident by construction.

Introduction

Section 2 of the MSMED Act defines acceptance, including deemed acceptance when the buyer files no written objection within 15 days of delivery; section 15 then fixes the payment deadline; section 16 fixes the interest. These are date-driven rules — perfect for software — yet most small suppliers apply them with a calculator. At the same time, examiners and employers keep asking what "blockchain" actually contributes to a business application beyond the buzzword. This project answers both: it uses the core cryptographic idea (a hash chain over an append-only log, with periodic root anchoring) where it genuinely helps — proving a record was not edited after the fact — and it refuses where it does not (no token, no distributed consensus for a one-party ledger).

Existing system vs proposed system

• Excel registers / Tally exports / e-mail threads: mutable, unversioned, no proof of when an entry was made; interest computed by hand; disputes become word-versus-word.
• GST e-invoicing: built for tax compliance, not for tracking acceptance dates, the 45-day clock or section 16 interest.
• Proposed: an event-sourced, hash-chained ledger with an integrity verifier, a statutory-clock engine (15-day objection window, 45-day due date, compound monthly-rest interest at 3× the configurable bank rate), dispute states mirroring the Samadhaan/ODR workflow, optional daily root-hash anchoring, and a dashboard with ageing buckets and defaulter rankings.

Feasibility study

• Technical: SHA-256 chaining is a few lines with the standard node:crypto module; SQLite in WAL mode gives a safe append-only store; React covers the dashboard. All steps run on a student laptop.
• Economic: zero licence cost — Node.js, SQLite, MySQL and React are free.
• Operational: single-supplier deployment with three roles (admin, accountant, read-only auditor); the interest engine is configurable so an RBI bank-rate change is a config edit, not a code change.
• Legal fit: the design never stores government ID numbers (GSTIN, Udyam, PAN, Aadhaar), and an integrity-verified log supports the kind of reliable electronic records the Information Technology Act contemplates — though admissibility questions stay outside the project's claims.

In scope

• A single supplier organisation (the MSME) recording invoices against many buyers; users are supplier staff plus a read-only auditor.
• Full invoice lifecycle: issue → delivery → objection/acceptance (actual or deemed) → due → paid / overdue → dispute → resolution or MSEFC referral.
• Hash-chained append-only event store (SQLite, WAL) with a MySQL read model for fast queries, an interest engine, an anchoring exporter and a React dashboard.
• Section 16 interest statements and an event-history annexure formatted for MSEFC/ODR filing support.

Out of scope (v1)

• No cryptocurrency, tokens, smart contracts on public chains, or multi-party consensus — the buyer does not run a node.
• No GST return filing, e-invoicing (IRN) generation or accounting-ledger replacement; the ledger complements, not replaces, Tally-style books.
• No payment-gateway integration; payments are recorded with a reference number (NEFT/UPI reference).
• No storage of statutory identifiers: GSTIN, Udyam registration number, PAN and Aadhaar are deliberately absent from the schema; parties are referenced by name and an internal code.
• No legal-advice features — the tool produces statements; filing and advocacy remain with the supplier and counsel.

The project follows an incremental SDLC with risk retired early — the hash chain and the interest engine are built first because everything else depends on them. It spans 16 weeks, matching the MCSP-232 project semester.

Testing approach: the interest engine is pinned by golden test cases computed by hand (including month-end and leap-month boundaries); the ledger has a property test that appends random valid events and asserts verifier success, and a tamper test that silently modifies a row and asserts the verifier fails; the API gets Jest integration tests; a 12-invoice demo dataset is validated with user-acceptance checklists.

The system is a small three-tier application with an event-sourced core. The presentation tier is a React dashboard for the supplier's staff and auditor. The application tier is an Express REST API that validates input, enforces roles, appends events and serves the read models. The data tier has two stores: SQLite in WAL mode holds the append-only event ledger (the system of record), and MySQL holds derived, rebuildable read models for fast queries — a separation that keeps the evidence store pure while the query side stays flexible.

Every mutation is an event: nothing in the ledger is ever updated or deleted. Corrections are new compensating events, which is what makes the hash chain meaningful. Each event stores its sequence number, type, canonical-JSON payload, timestamp, the previous event's hash, and its own SHA-256(previousHash + canonical JSON). The verifier recomputes the chain; a daily job exports the latest hash as an anchor that can be preserved outside the system (printed register, e-mail, or later a public timestamping service) to prove the state existed that day.

flowchart TD
  S(["Supplier admin / accountant"]) -->|"invoice, acceptance, payment events"| API["Express REST API"]
  A(["Auditor (read-only)"]) -->|"verify, view"| API
  API --> V["Payload validation + role check"]
  V --> EV["Append event: seq, type, payload, recorded_at"]
  EV --> HC["Hash chain: SHA-256(prevHash + canonical JSON)"]
  HC --> ST[("SQLite ledger - append-only, WAL")]
  ST --> VF["Integrity verifier: recompute full chain"]
  ST --> RM["Read-model builder (rebuildable)"]
  RM --> MY[("MySQL query index")]
  RM --> IE["Statutory engine: 15-day objection, 45-day due date, s.16 monthly-rest interest"]
  ST --> AN["Anchor service: daily root hash export"]
  AN --> EXT["Preserved outside: printed register / e-mail / public timestamping"]
  MY --> UI["React dashboard: ageing, statements, defaulters, integrity badge"]
  IE --> UI

Ledger schema (core tables)

erDiagram
  INVOICE_STATE ||--o{ LEDGER_EVENT : "is built from"
  INVOICE_STATE ||--o{ DISPUTE : "may enter"

  LEDGER_EVENT {
    int seq PK
    string event_type
    string payload_json
    string prev_hash
    string hash
    datetime recorded_at
  }
  INVOICE_STATE {
    int invoice_seq PK
    string invoice_no
    string buyer_code
    int amount_paise
    string state
    date acceptance_date
    date due_date
    int overdue_days
  }
  DISPUTE {
    int dispute_seq PK
    string invoice_no
    string status
    date raised_on
    date resolved_on
  }

Invoice lifecycle and dispute states

flowchart TD
  I["Issued"] --> DL["Delivered"]
  DL -->|"no written objection in 15 days"| DA["Deemed accepted (s.2)"]
  DL -->|"objection filed"| OR["Objection raised"]
  OR -->|"objection removed"| DA
  DL -->|"accepted in writing"| DA
  DA --> DUE["Due within 45 days (s.15)"]
  DUE --> P["Paid in full"]
  DUE --> OV["Overdue - s.16 interest running"]
  OV --> PP["Part payment recorded"]
  PP --> OV
  OV --> DP["Disputed by buyer"]
  DP --> RS["Resolved / settled"]
  DP --> MF["Referred to MSEFC / ODR (s.18)"]

Level-2 DFD — statutory engine

flowchart LR
  API(["REST API"]) --> P1["2.1 Validate event payload"]
  P1 --> P2["2.2 Append to hash chain"]
  P2 --> D1[("D1: Ledger events")]
  D1 --> P3["2.3 Derive invoice state"]
  P3 --> D2[("D2: Invoice state")]
  D2 --> P4["2.4 Compute ageing and s.16 interest"]
  P4 --> D3[("D3: Interest statements")]
  P4 --> U(["Dashboard / auditor"])

• Merkle-tree anchoring with inclusion proofs and an OpenTimestamps-style public anchor, so a single invoice's event can be proven against the daily root without revealing the rest.
• Two-party lite network: a signed-event exchange where the buyer's system countersigns acceptance events, adding non-repudiation without full consensus.
• Accounting integration: Tally XML import/export so the ledger mirrors an existing books of account without re-entry.
• MSEFC filing pack generator: a single ZIP with the interest statement, event annexure and anchor log laid out for the ODR portal's attachment requirements.
• Buyer risk scoring: defaulter rankings across the supplier's history with trend charts for credit decisions.
• Mobile companion for delivery-recording with geotagged proof photos hashed into the chain at capture time.