E-way bill 14-digit numbers from 1 January 2027: the ERP and API fix list

Summary. GSTN's advisory of 4 November 2026 says the e-way bill system is running out of numbers because of the volume generated, and proposes two format changes with effect from 1 January 2027: the e-way bill number grows from 12 digits to 14, and the consolidated e-way bill number from 10 digits to 11. Taxpayers, GSPs, ERP vendors and API integrators are told to update applications, APIs, database schemas and validation rules, and a sandbox build is promised shortly, with details to follow on the E-Way Bill Portal. On 11 November 2026, 51 days before the date, NIC's API documentation still types the e-way bill number as Number(12), and neither NIC's developer portal nor the E-Way Bill Portal has published anything on the change. The fix list is short to write and long to test: widen columns, accept both old and new lengths, update any routing that tells the two document types apart by length, move 32-bit consolidated fields to 64-bit or text, and re-test IRP responses, print templates, scanners and partner feeds. E-way bills generated in late December will still be moving in January, so both lengths must coexist. Separately, the RCMDOM and RCMIMP self-invoice supply types sit in the sandboxes of all six IRPs with no production date.

About this article. For ERP, WMS and integration leads at Indian companies that generate e-way bills or e-invoices, and for the GSPs and software vendors who serve them. We checked every date, field type and rule against GSTN advisories on the GST portal, NIC's e-way bill and e-invoice API documentation, the CBIC notification on e-way bill validity, and vendor database and language documentation, on 11 November 2026. This is general information, not tax or legal advice; GSTN calls the format proposed and has not published sandbox specifications, so re-check the E-Way Bill Portal before you freeze code. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What GSTN's 4 November advisory says

The advisory is dated 4 November 2026, filed under the E-Way Bill module of the GST portal and titled Revision in E-Way Bill and Consolidated E-Way Bill Numbering Formats w.e.f. 1 January 2027. The portal draws the page with JavaScript, so we read the text from the portal's own news feed. In substance it says four things:

• The existing numbering capacity is expected to run out because of the volume of e-way bills generated.

• The formats below are proposed with effect from 1 January 2027.

• Taxpayers, GSPs, ERP and software providers and API integrators should change their applications, APIs, database schemas and validation rules.

• The changes will reach the sandbox shortly, details will be published on the E-Way Bill Portal, and stakeholders should be ready well before 1 January 2027.

The advisory's table, as published on 4 November 2026:

Note the word proposed. GSTN gives no alternative date, but its table labels the new column as the proposed format, and GSTN paused a different e-way bill package earlier this year (see below). Plan for 1 January, and design so that a short delay costs nothing.

What has not been published yet

The advisory tells you what changes, not how. These gaps decide how defensive your code needs to be.

NIC's e-way bill developer portal lists 30 July 2026 as its newest announcement, and that one put the Ship-to GSTIN and EWB closure changes on hold; its release notes say nothing about numbering. The E-Way Bill Portal's latest-updates list ends at 27 January 2026. Check both weekly.

Where 12 digits hide in your stack: the fix list

Most teams will find the e-way bill number in more places than they expect. A code search for ewb finds the obvious ones; the rest live in report definitions, mobile forms and partner files.

Two rows deserve extra attention.

The consolidated EWB integer trap. A signed 32-bit integer tops out at 2,147,483,647, so a 10-digit consolidated number fits only if it stays at or below that value. No 11-digit number fits: the smallest is 10,000,000,000. Any service, report or mobile app that stores the consolidated number as a 32-bit integer will fail or corrupt data on the first 11-digit value.

Length-based type inference. Today the two document types differ by length (12 against 10), and some ERPs use that to route a number to the right lookup. After 1 January the valid lengths are 10, 11, 12 and 14. They are still distinct, so the trick survives, but only if someone updates the mapping.

Database and type changes

Fourteen digits is small for modern runtimes. JavaScript's largest safe integer is 9,007,199,254,740,991, which has 16 digits, so a 14-digit number parsed from JSON stays exact. A signed 64-bit BIGINT holds values up to 9,223,372,036,854,775,807, which is 19 digits. The risk sits in older schemas, fixed-width text and 32-bit fields.

We recommend storing both numbers as text with a format check, because GSTN has not said whether new numbers can begin with zero, and text avoids any padding debate. If you keep a numeric type, widen it and add a range check.

            -- Illustrative migration (PostgreSQL syntax). Adapt names and test on a copy first.
ALTER TABLE shipment_documents
  ALTER COLUMN ewb_no  TYPE varchar(20),
  ALTER COLUMN cewb_no TYPE varchar(20);

-- Accept both lengths during the changeover window.
ALTER TABLE shipment_documents
  ADD CONSTRAINT ewb_no_format  CHECK (ewb_no  IS NULL OR ewb_no  ~ '^[0-9]{12}([0-9]{2})?$'),
  ADD CONSTRAINT cewb_no_format CHECK (cewb_no IS NULL OR cewb_no ~ '^[0-9]{10,11}$');
          

In PostgreSQL, changing a column's type normally rewrites the whole table and its indexes; the exception is a change where the old type is binary coercible to the new one, such as widening a varchar. Moving from numeric to text is a rewrite, so on large shipment or invoice tables schedule it outside dispatch peaks, and consider adding the check constraints as NOT VALID and validating them afterwards. Re-run any materialised views or reports that copy the widened columns.

API changes: the e-way bill API and the e-invoice IRP

Two integration paths return e-way bill numbers, and most mid-market companies use both.

The NIC e-way bill API. A successful Generate E-way Bill response returns ewayBillNo as a number (the sample is 123456789012) with ewayBillDate and validUpto. The Cancel API declares ewbNo as Number(12) in its data structure and as a JSON number in its schema. The Extend Validity API and the trip-sheet list inside Generate Consolidated E-way Bill declare ewbNo the same way. Every API that takes an e-way bill number as input (Part-B and vehicle updates, extension, cancellation, rejection, consolidation, multi-vehicle movement and the transporter lookups) needs the same review. Expect NIC to revise these definitions when the sandbox opens.

NIC's own samples already disagree on type. The Cancel API's encoded response sample carries ewayBillNo as a quoted string, while the decoded version beside it shows a number, and the consolidated response returns cEwbNo as a string. Your parser should not care.

The e-invoice IRP path. Where the supplier is enabled for e-invoicing, the e-way bill API blocks direct generation for B2B and export transactions with document type Tax Invoice dated on or after 1 October 2020; those e-way bills must be generated with the IRN or by reference to it through the e-invoice system. For many ERPs, then, the e-way bill number arrives in an IRP response as EwbNo, with EwbDt and, when Part-B details were supplied, EwbValidTill. ClearTax's documentation of the government-compatible Generate E-Waybill by IRN API lists EwbNo as a string in its parameter table, while its sample response returns a bare number. Integrations should accept both.

            import re

EWB_RE  = re.compile(r"[0-9]{12}([0-9]{2})?")  # 12 digits now, 14 from 1 Jan 2027
CEWB_RE = re.compile(r"[0-9]{10,11}")          # 10 digits now, 11 from 1 Jan 2027

def normalise_ewb(value) -> str:
    """Accept EwbNo / ewayBillNo / ewbNo as int or str; return a validated string."""
    if isinstance(value, (float, bool)):
        raise ValueError(f"Refusing non-integer e-way bill number: {value!r}")
    s = str(value).strip()
    if not EWB_RE.fullmatch(s):
        raise ValueError(f"Unexpected e-way bill number format: {s!r}")
    return s

def classify(number: str) -> str:
    """Length-based routing still works, with the new lengths added."""
    return {12: "EWB", 14: "EWB", 10: "CEWB", 11: "CEWB"}.get(len(number), "UNKNOWN")
          

Never parse a number that arrived as a JSON float, and do not let a client library or spreadsheet export coerce long digit strings into scientific notation. If your GSP or ASP wraps these APIs, ask for its release date, its sandbox test window and whether its own response types change.

The changeover window: both lengths at once

The switch does not happen at one instant for your data. Notification No. 94/2020-Central Tax of 22 December 2020 amended rule 138(10) of the CGST Rules so that, from 1 January 2021, an e-way bill for ordinary cargo is valid for one day for the first 200 km and one more day for every further 200 km or part of it. A 2,000 km road movement generated on 30 December 2026 therefore carries a 12-digit e-way bill valid for ten days, to about 9 January 2027. If the goods are delayed, the transporter can extend validity in a window from 8 hours before to 8 hours after expiry, against that same 12-digit number. Our logistics build guide covers the other e-way bill rules a dispatch flow has to respect.

Plan for these cases explicitly:

1. A 12-digit e-way bill generated in December and updated (Part-B, vehicle change) in January.

1. A 12-digit e-way bill extended in January, with a goods receipt or delivery proof recorded against it.

1. A consolidated EWB generated in January (11 digits) that groups 12-digit e-way bills from December.

1. A cancellation in January of a 12-digit e-way bill generated late on 31 December, inside the 24-hour cancellation window the Cancel API documents.

1. Historical searches, audits and reports that span both years.

Case 3 is the one most likely to break a schema: a single record that holds an 11-digit parent and 12-digit children.

The other GSTN change in the queue: RCMDOM and RCMIMP

The same ERP teams have a second GSTN item open. At its 57th meeting on 8 October 2026, the GST Council recommended a package of compliance reforms. GSTN's advisory of 16 October 2026 says the Council recommended extending e-invoicing to domestic supplies received from unregistered persons under reverse charge, and to imports of services, for taxpayers with aggregate annual turnover (AATO) of ₹5 crore and above. It adds two supply types:

GSTN says both are live in the sandboxes of all six authorised IRPs: NIC IRP-1, NIC IRP-2, Cygnet IRP-3, Clear IRP-4, EY IRP-5 and IRIS IRP-6. Scope, applicability and the effective date depend on notifications still to be issued, and the production date will be communicated later. NIC IRP-1 has already published its release note, dated 16 October 2026: only the recipient registers these invoices, the IRN hash is calculated on the recipient's GSTIN, the supplier is always URP, RCMIMP allows only services with an origin country outside India, and no e-way bill is generated for either type. The same release note splits the SEZWP supply type into SEZWPA and SEZWPNA, with GSTN's advisory on that marked as awaited, so check your supply-type enums too.

For ERP teams this is a purchase-side change: a new IRN flow triggered from accounts payable, not sales. Build it in the same release train as the e-way bill change, behind a flag, and switch it on when the notification arrives.

Also on hold: the June 2026 e-way bill enhancements

Do not confuse the numbering change with an earlier package. GSTN's advisory of 29 July 2026 put on hold, until further notice, the enhancements announced in its advisories of 9 June and 17 June 2026 (with FAQs of 2 July and a planned date of 1 August 2026), told stakeholders that no production changes were needed under them, and said the advisories and FAQs would be withdrawn from the portal. NIC lists the paused items as mandatory Ship-to GSTIN capture and voluntary EWB closure. Our Ship-to GSTIN integration guide explains what those advisories proposed. If your team built against them, keep that code dormant and separate from the 14-digit work.

Testing on sandbox: a practical plan

Until GSTN's sandbox build appears, test against your own fixtures, then run the same suite against the sandbox when it opens. NIC's API portal notes that e-way bills generated through the sandbox API can be viewed on a sandbox website using your API login. For the IRP path, NIC runs an e-invoice developer sandbox, and GSTN points integrators to each IRP's own sandbox.

1. Generate e-way bills directly and through the IRP, and confirm both paths store 14-digit numbers end to end.

1. Generate a consolidated EWB and confirm an 11-digit value round-trips through every system that stores it.

1. Run Part-B update, extension, cancellation and rejection against both 12-digit and 14-digit numbers.

1. Send 14-digit values through every outbound feed: transporter, 3PL, WMS, customer portal and BI.

1. Print, scan and re-key a 14-digit e-way bill on each handheld and gate device.

1. Upload a bulk template with 14-digit values and confirm nothing turns into scientific notation.

1. Run negative tests: 13 digits, 15 digits, letters, leading and trailing spaces.

1. Reconcile document counts and EWB numbers between ERP and portal for a full test day.

A 51-day plan to 1 January

If GSTN moves the date, nothing above is wasted: code that accepts both lengths works either way.

Decision table: who does what

Implementation checklist

1. Search code, schemas, reports, mobile forms and partner specs for every use of the EWB and consolidated EWB numbers.

1. Widen database columns and move any 32-bit consolidated EWB fields to 64-bit or text.

1. Replace 12-digit and 10-digit validations with rules that accept old and new lengths.

1. Map 12 and 14 to EWB, and 10 and 11 to consolidated EWB, wherever routing uses length.

1. Make API clients accept ewayBillNo, ewbNo and EwbNo as either number or string.

1. Ship mobile, handheld and scanner updates before the December freeze.

1. Agree file formats with transporters, 3PLs and customers.

1. Run the sandbox test plan as soon as GSTN releases the build.

1. Keep the June 2026 e-way bill enhancement code dormant; it is still on hold.

1. Scope RCMDOM and RCMIMP self-invoicing behind a feature flag.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. For the 14-digit change our ERP software development team can inventory every place the number lives, change schemas, validations and API clients, and have a sandbox test suite ready for GSTN's build. Talk to us at /contact-us/.

Last updated: 11 November 2026.

References

1. Revision in E-Way Bill and Consolidated E-Way Bill Numbering Formats w.e.f. 1 January 2027, 4 November 2026 — GSTN, GST portal

1. News and Updates feed (JSON source of the GSTN advisories cited here), read 11 November 2026 — GSTN, GST portal

1. Cancel E-way Bill API, version 1.03 — National Informatics Centre

1. E-Way Bill API Developer's Portal, home and announcements — National Informatics Centre

1. E-Way Bill System home and latest updates — National Informatics Centre

1. Introduction of e-Invoicing Facility for Recipient Generated Self Invoices under RCM (RCMDOM and RCMIMP), 16 October 2026 — GSTN, GST portal

1. E-Way Bill API release notes, updated 30 July 2026 — National Informatics Centre

1. Numeric Types — PostgreSQL Documentation

1. Number.MAX_SAFE_INTEGER — MDN Web Docs

1. ALTER TABLE — PostgreSQL Documentation

1. Generate E-way Bill API, version 1.03 — National Informatics Centre

1. Extend Validity API, version 1.03 — National Informatics Centre

1. Generate Consolidated E-way Bill API, version 1.03 — National Informatics Centre

1. Generate IRN API, version 1.03 — National Informatics Centre, e-Invoice API sandbox

1. Get e-Way Bill Details by IRN API, version 1.03 — National Informatics Centre, e-Invoice API sandbox

1. Generate E-Waybill by IRN, government-compatible APIs — ClearTax

1. Notification No. 94/2020-Central Tax, 22 December 2020 (archived copy) — CBIC

1. Recommendations of the 57th GST Council Meeting, 9 October 2026 — GSTN, GST portal

1. e-Invoice API release notes, 16 October 2026 — National Informatics Centre, e-Invoice API sandbox

1. Advisory on Keeping on Hold the Proposed e-Way Bill Enhancements, 29 July 2026 — GSTN, GST portal

1. e-Invoice API Developer's Portal, home and announcements — National Informatics Centre