Skip to content

e-Way Bill Setup

Applies to: e-Way Bill · Which modules do I have?

Purpose

Prove both e-Way Bill pipelines end to end in the sandbox, and — at least as important — establish the dispatch process that keeps Part-B from being forgotten once real goods start moving.

Audience

The implementation consultant, with the customer's logistics or dispatch lead.

Prerequisites

  • e-Invoice Setup gate passed, for the from-a-reference-number pipeline
  • Transporter master data loaded
  • The customer's actual dispatch and transport lead times
  • Logistics users available for testing

Steps

1. Confirm which pipelines are in scope

Pipeline Source In scope if
From a registered reference number A tax invoice Taxable supplies move goods
From a standalone document A challan, bill of supply, bill of entry Non-invoice movements occur

Most customers need both. Test each separately — they behave differently and fail differently.

2. Test generation from a reference number

Step Confirm
Register a document Reference number obtained
Generate the bill from it Bill issued, with a validity period
Check validity Consistent with the distance supplied
Print Renders correctly

3. Test standalone generation

Repeat for a challan. Confirm it produces a bill and no reference number — that is the correct behaviour for that document type, and confirming it here prevents a ticket later.

4. Test distance handling

Case Expected
Distance supplied Used as given; validity follows
Distance supplied as zero Computed from postal codes; validity sensible
A wrong postal code An absurd distance and validity — which is exactly how this fault presents in production

The third case is worth doing deliberately, so the team recognises the signature: unexpected validity means the distance is wrong.

5. Test Part-B, and design the process around it

Update the vehicle on a test bill and confirm Part-B is recorded.

Then do the more important work: establish who completes Part-B, and when.

Question Must have an answer before go-live
Who completes Part-B? A named role, not "logistics"
At what point in dispatch? Before the vehicle leaves. Always
How do they know a bill is waiting? A screen, a report, or an alert
What happens if the vehicle changes? Update Part-B before it moves again

Goods stopped in transit is almost always Part-B, and it is almost always a process failure rather than a software one. This step is where it is prevented.

6. Test extension and cancellation

Test Expected
Extend a bill near expiry Extended, with the reason recorded
Extend a bill not near expiry Refused — statutory, and worth the team seeing
Cancel inside the window Cancelled
Cancel outside the window Refused; rejection by the other party is the alternative

7. Test consolidated bills and multi-vehicle, if in scope

Check the provider's capability first. An operation may be deliberately disabled — that is the platform declining to fabricate a number the government never issued, not a fault.

If it is unavailable and the business needs it, that is a stage 7 finding, not a go-live surprise.

8. Set the expiry alert horizon

Set it from the customer's actual lead times. Then test it: create a bill nearing expiry and confirm the alert arrives with time to act.

An alert that arrives after the decision point is noise; one that arrives far too early is ignored. Both end with an expired bill.

9. Confirm authority

Sign in as a logistics user and confirm they can do the full bill workflow and cannot register a document. This verifies the logistics separation.

Validation

Gate: this stage is complete when all of these pass.

Check Pass condition
Both pipelines work From a reference number, and standalone
Validity is sensible Consistent with distance
Part-B works Recorded, and the bill becomes valid for movement
The Part-B process is defined Named owner, defined point in dispatch, defined trigger
Extension tested Both inside and outside the window
Cancellation tested Both inside and outside the window
Consolidated and multi-vehicle Tested, or their unavailability recorded and accepted
Expiry alerts tested Arrive with time to act, to a distribution list
Authority enforced Logistics cannot register documents

The Part-B process row is the one that prevents real-world incidents. Everything else on this list is software.

Rollback

Situation Action
Test bills clutter the sandbox Leave them; they are sandbox records
Wrong configuration found Correct and re-test
Alert horizon wrong Change it; effective immediately
A bill generated in production during testing Cancel it within its window. If outside, rejection by the other party is the route

Common mistakes

Mistake Consequence Avoid by
Testing only the reference-number pipeline Standalone movements fail after go-live Test both
Not defining the Part-B process Goods stopped in transit Name the owner and the point in dispatch
Default expiry horizon Alerts after the decision point Use actual lead times
Not testing extension refusal The team meets the statutory limit for the first time in production Test it
Assuming consolidated bills are available A capability gap found at go-live Check the matrix at this stage
Alerts to individuals Nobody receives them later Distribution lists
Not testing a wrong postal code The team does not recognise the signature Test it once

Troubleshooting

Symptom Cause Action
Validity much shorter than expected Distance understated, usually a postal code Correct the postal codes
Cannot generate from a reference number The source document is not registered Register it first
Extension refused Outside the extension window Statutory. Not configurable
Consolidated generation unavailable Provider capability Check the matrix; record the gap
Part-B forgotten in testing No process defined Define it now, not after go-live
Alerts not arriving Notification configuration, or the horizon Test to a real mailbox