A working account of three issues a Kottayam-based Shopify merchant ran into with their GST invoicing  and how each was diagnosed and resolved.

 21 months 3 of 3 July 2024
Active engagement (as of April 2026) Critical issues fully resolved Onboarded onto GST Pro


The Summary 

Suluz Orchids is a Shopify merchant in Bharanikavu, Kerala selling rare orchid plants. They onboarded onto GST Pro in July 2024 and ran into three operational issues within the first months of active use:

  • Customer details on PDF invoices rendered as empty boxes when names or addresses contained characters outside the basic ASCII range, traced to limitations in the older PDF rendering service.
  • The default invoice layout did not match what their accounts team needed for GST filing specifically, a product-only tax base with shipping shown separately.
  • Items removed or refunded from Shopify orders kept appearing on packing slips, creating mismatches between the printed slip and what was actually shipped.

Each issue called for a different kind of intervention: a backend infrastructure migration, a custom invoice template build done in collaboration with the accounts team, and a Liquid template fix that distinguishes Shopify's "removed" and "refunded" line-item states. None of the three issues have recurred. The engagement is ongoing.

About the client

Suluz Orchids (suluzorchids.com) is a small horticultural business operating out of Bharanikavu, Kerala. They ship live plants, orchids, adeniums, growing media across India and use Shopify as their storefront. They have been a GST Pro customer since July 2024.

GST Pro features actively used: GST-compliant invoicing · GST reports · credit notes and refund handling.

The Challenge  

When Suluz Orchids began generating GST invoices at scale, three problems surfaced.

Issue 1 - Customer names and addresses rendering as boxes on PDF invoices

 Invoice 540/25-26 with the customer's name, address, and place of supply rendering as empty boxes — the symptom of missing font support in the PDF generator.

Some customer-facing PDFs were going out with the customer's name, billing address, shipping address, and "Place of Supply" field rendered as a row of empty boxes (□□□□). The order data inside Shopify was clean, the issue was confined to the PDF output. Because it only affected orders containing certain characters in customer-entered fields, the issue was intermittent and slow to diagnose initially.

Issue 2 - Tax breakdown layout did not match accounts team requirements

The default invoice combined product taxes and shipping into a single tax line. The Suluz accounts team needed a layout with:

  • Product subtotal shown before discount
  • CGST, SGST, and IGST calculated only on product value (not on shipping)
  • Shipping shown as a separate line in the final total
  • Discount and round-off shown distinctly

Without this, every order required offline reconciliation before the invoice could be used in their GST filing workflow.

Issue 3 - Removed and refunded items appearing on packing slips

When an item was removed from a Shopify order for example, when a product was found to be out of stock after the order was placed or when a partial refund was issued, those line items continued to appear on GST Pro's packing slips. The printed slip showed items that were not actually being shipped.

How we approached it

Three different solution shapes for three different causes but one principle running through all of them: fix the cause, not the visible symptom.

 Issue Where the cause lived What we changed
Font rendering Backend PDF generation service Migrated production to a newer Lambda runtime with proper font support
Tax layout Invoice template logic Rebuilt the template with the client's accounts team, two iterations
Refunded items Liquid template quantity logic Added net-quantity computation; suppress items where net quantity is zero

Across all three, we spent extra time on the why particularly for Issue 3, where Shopify's distinction between "removed" (pre-fulfilment) and "refunded" (post-fulfilment) line items is not obvious. Closing the knowledge gap reduced repeat questions later in the engagement.

Implementation details

Issue 1: PDF font rendering

The same invoice (540/25-26) after the Lambda migration. Customer name and address now render correctly.

Root cause. The PDF generation service was running on a Node 12-based Lambda whose font configuration did not include glyph support for some extended character sets present in customer-entered fields.

Action. Verified the issue across multiple invoice outputs. Tested rendering on both the legacy Lambda and an updated runtime. Confirmed the issue was resolved on the new environment. Migrated production by switching the Lambda URL.

Scope. This was a platform-level change. Every GST Pro merchant whose customer or address fields include extended characters benefits from the upgrade — not just Suluz Orchids.

Issue 2: Custom invoice with product-level tax breakdown

The customized invoice template. The highlighted totals block shows product subtotal, separate CGST and SGST calculated only on product value, shipping as a distinct line, and the final total.

Requirement. A revised totals block showing: Sub total · Total Discount · Total Amount before Tax · Total Amount after Tax · Total Shipping · Total Tax Amount · CGST and SGST on product value only · Round Off · Total.

Process. Reviewed a sample invoice from the client's accounts team. Built the new layout. Sent for review. Made one round of changes. Signed off.

Outcome. The accounts team approved the layout for direct use in their filing workflow. No further change requests on this template have been raised since.

Issue 3: Packing slip net quantity after refunds

Order #6412 in Shopify shows "Aztec Clay Ball 2L" in the Removed section (left). The GST Pro packing slip for the same order correctly excludes that item (right).
Root cause. The packing slip template iterated over original line items without subtracting refunded quantities. Shopify's data model distinguishes "removed" items (taken off before fulfilment) from "refunded" items (post-fulfilment); the template was not handling the latter case.

Action. Updated the Liquid template to compute the net quantity after refund and skip rendering when the net is zero:

{% assign final_quantity = line_item.quantity | minus: refunded_quantity %}
{% if final_quantity > 0 %}
  <!-- render line item -->
{% endif %}

Compliance note. Invoices continue to retain refunded line items alongside the corresponding credit note, this is the correct treatment for GST. Only packing slips, which represent physical shipment, exclude the refunded quantities.

Results

 Metric Before After
Invoice character rendering errors Present on orders with extended characters in customer/address fields None observed since the Lambda migration
Tax layout suitable for direct use in GST filing No required offline reconciliation Yes accounts team uses invoices directly
Packing slip accuracy after order edits Removed and refunded items appeared on slip Only net-positive quantities are shown

Key takeaways

Default templates rarely survive contact with a real accounting workflow. All three issues stemmed from defaults that were reasonable in the abstract but did not match how the client actually operated. Pulling the accounts team into the invoice template review on Issue 2 is what prevented further iteration cycles after delivery.

Platform-level fixes compound. The Lambda migration on Issue 1 fixed the rendering problem for every GST Pro merchant whose customer data includes extended characters not just for Suluz Orchids.

Explaining the cause matters as much as fixing the symptom. Issue 3 was not just a code change; it was also a clarification of how Shopify's data model distinguishes removed from refunded items. Once the client understood the distinction, an entire category of follow-up confusion went away.