The payment tool you switched to for convenience can quietly break your paper trail
Wire transfers made the purpose code straightforward: your bank recorded it once, matching the SOFTEX or export declaration for the same receipt. A modern payment aggregator handling the same collection can default to a generic code instead of the correct one for software or IT services. The bank doesn't necessarily reject the payment outright, but a code that doesn't agree with your own export filings can leave the receipt open and unreconciled, and later payments through the same channel queried, until someone actually corrects it.
Cross Rs 5 crore once, and export invoices need an IRN forever after
E-invoicing, generating an IRN and QR code for every invoice through the government portal, becomes mandatory the moment your aggregate turnover crosses Rs 5 crore in any financial year, and there's no exception carved out for export supplies just because they're already zero-rated under LUT. The trigger is also permanent: cross it once, even in a single strong year, and the requirement applies going forward regardless of what turnover does afterwards. An export invoice issued without a valid IRN once this applies isn't treated as a technicality, it's treated as not a valid invoice at all, which is exactly the kind of gap a refund claim can get stuck on.
What goes wrong without a CA
The recurring pattern: the business switches payment collection tools for lower fees or faster settlement, without checking whether the new tool records the same purpose code the old bank did, and separately crosses Rs 5 crore without anyone flagging that this quietly switches on a permanent e-invoicing requirement. Both surface the same way, months later, when a GST refund claim stalls on a documentation question nobody was watching for, not because the underlying export wasn't genuine, but because the paperwork behind it stopped matching what the rules now require.