Skip to content
Robnu
GST · How-to guide

Building GSTR-1 from AJIO and Meesho reports, without the month-end panic.

Your GSTR-1 is only as good as the working file behind it — and that file has to be rebuilt every month from panel exports that disagree with each other about dates, values, and what counts as a sale. Here is the spreadsheet-first method: which reports to pull, how they map to GSTR-1, and where the cutoff traps hide.

Free during early access · Forever free under 25 orders/day
app.robnu.com/gst/gstr-1The month-end working file, stage by stageIllustrative flow — from panel exports to a filed, reconciled GSTR-1Pull panel reportssales + returns + tax, both marketplacesday 1Fix the date basisone rule, applied to every rowday 1Map to GSTR-1 tablesB2C supplies, rate-wiseday 2Net returns as credit notesmatched to original ordersday 2Reconcile TCS vs GSTR-8their turnover vs yoursday 3File & archive the workingssame structure every monthdoneThree focused days beats one panicked due-date night — and the archive saves you when a query comes.
TL;DR
  • Pull three reports per marketplace on the 1st: order-level sales, returns, and the panel's tax report. Build one working file with a fixed column structure, and never file from a settlement summary — settlements are about money movement, not supplies.
  • The biggest trap is the date basis: order, dispatch, delivery, and settlement are four different dates for the same sale. Pick the invoice-date basis, apply it to every row on both marketplaces, and handle returns as credit notes — including last month's late returns.
  • AJIO and Meesho file GSTR-8 about you; the portal shows their version for acceptance. Reconcile their implied turnover against your GSTR-1 before filing — the system compares the two whether or not you did.
Why reports disagree

One order, four dates, three values

Every marketplace order exists in at least four moments: the day it was placed, the day it dispatched, the day it delivered, and the day it settled into your bank. Panel reports slice by different ones — a sales report keyed on order date and a settlement report keyed on payout date will disagree about any month, forever, and both are right. GSTR-1 cares about when the supply was invoiced, so your working file needs one date rule applied to every row, and the discipline to ignore the other three.

Values split the same way: the buyer-paid price is GST-inclusive, GSTR-1 wants taxable value and tax rate-wise, and the settlement amount — after commission, shipping, and deductions — is a different number that belongs in your P&L, not your GST return. The working file's job is to carry all of these per order and let each report take the column it needs. Build it once with fixed columns, and month two becomes a paste-and-refresh job instead of a rebuild.

app.robnu.com/reconciliation/2026-04Payment reconciliationPayouts ↔ Orders ↔ Adjustments — line by linePayoutsAJIO settlement fileOrdersshipped + deliveredAdjustmentsdeductions + claimsMatch enginededup_key + amount + AWBOR-7782 · ₹1,249 · ✓OR-7783 · −₹47 · ΔOR-7784 · ₹890 · ✓ReconciliationBatch · BATCH-2026-04-26218 matched · 7 deltas · ₹1,348 recoverable₹+1,348
The method

Seven steps from panel export to filed return

The same sequence works for AJIO, Meesho, or both together — the point is that it is the same sequence every month, in a file with the same shape every month.

  1. 01

    Download everything on the 1st

    Sales, returns, and tax reports from both panels, saved with a naming convention (marketplace-report-YYYY-MM). Panels restate data and archive old months; the copy you download on the 1st is your defensible snapshot.

  2. 02

    Load into one working file

    One sheet per marketplace, one consolidated sheet on top. Keep the panel's raw columns untouched and add your own calculated columns beside them — when a number is questioned later, you can show exactly how it was derived.

  3. 03

    Apply the date rule

    Filter every row to the filing month using the invoice-date basis, identically on both marketplaces. Flag boundary rows — the 30th/31st and the 1st/2nd — for a manual look; month-end cutoffs are where duplicated and dropped orders live.

  4. 04

    Split taxable value by rate

    Back GST out of inclusive prices and pivot by rate slab and HSN. Marketplace B2C sales land in GSTR-1's consumer-supply tables; your CA or filing tool needs rate-wise totals, and interstate supplies split by state of delivery.

  5. 05

    Build the credit-note sheet

    Every return and RTO that reversed a sale becomes a credit-note row, matched to its original order ID. Late returns against last month's sales are normal — report them as this month's credit notes rather than editing history.

  6. 06

    Reconcile TCS before filing

    Open the portal's TCS view: each marketplace's GSTR-8 filing implies a turnover (TCS ÷ 0.5%). Compare against your working file per marketplace. Timing noise around returns is fine; a structural gap means missing rows — find them now.

  7. 07

    File, then freeze the workings

    After GSTR-1 is filed, lock the month's file and archive it with the raw downloads. When a query lands eight months from now, the frozen working file is the difference between a one-line reply and a week of reconstruction.

app.robnu.com/reconciliation/2026-04Payment reconciliationPayouts ↔ Orders ↔ Adjustments — line by linePayoutsAJIO settlement fileOrdersshipped + deliveredAdjustmentsdeductions + claimsMatch enginededup_key + amount + AWBOR-7782 · ₹1,249 · ✓OR-7783 · −₹47 · ΔOR-7784 · ₹890 · ✓ReconciliationBatch · BATCH-2026-04-26218 matched · 7 deltas · ₹1,348 recoverable₹+1,348
What sloppiness costs

A wrong GSTR-1 is a slow leak, not a bang

Overstate turnover — usually by missing credit notes — and you pay GST on sales that came back to you. Illustrative math: a seller doing ₹1,50,000 a month with a 15% return rate who skips credit notes pays tax on ₹22,500 of reversed sales; at a 5% slab, that is roughly ₹1,000 a month of tax on goods sitting back on your own shelf. Understate turnover — usually a date-basis mix-up — and the GSTR-8 comparison flags you the other way, which is the direction that draws queries, interest on short-paid tax, and in sustained cases, scrutiny of past periods too.

And then there is the quiet cost: a two-marketplace seller doing this by hand typically loses one to three days a month to the working file. That is a day of dispatch, sourcing, or catalog work — every month — spent re-deriving numbers that were knowable at order time.

The cutoff trap, specifically
Orders placed on the 30th, dispatched on the 1st; returns arriving on the 3rd against sales from the 25th. Whatever your date rule, the first and last three days of a month are where doubles and gaps happen. Reconcile boundary rows by order ID against last month's frozen file before you trust the totals.
The Robnu way

The working file shouldn't need building — it should already exist

Everything in this guide is reconstruction: pulling exports after the fact and stitching a month back together. Robnu sits on the other side of that problem. Because it runs your AJIO and Meesho order processing end-to-end, it records every order, return, and deduction the moment it happens — one consistent, order-level ledger across both marketplaces, already reconciled against settlements.

Month-end, you export instead of rebuild: sales with dates and values on one basis, returns matched to original orders, marketplace fees itemised with their GST. Your CA maps it to GSTR-1 in one sitting, and the GSTR-8 comparison stops being a surprise — because your numbers and the marketplace's came from the same orders all along.

app.robnu.com/reconciliation/2026-04Payment reconciliationPayouts ↔ Orders ↔ Adjustments — line by linePayoutsAJIO settlement fileOrdersshipped + deliveredAdjustmentsdeductions + claimsMatch enginededup_key + amount + AWBOR-7782 · ₹1,249 · ✓OR-7783 · −₹47 · ΔOR-7784 · ₹890 · ✓ReconciliationBatch · BATCH-2026-04-26218 matched · 7 deltas · ₹1,348 recoverable₹+1,348
FAQ

GSTR-1 from marketplace reports, answered

Three per marketplace, every month: the sales or order-level report (order value, taxable value, tax, HSN, order date), the returns report (which sales reversed and when), and the marketplace's own tax or GST report if the panel offers one — it is the closest thing to what the marketplace will report about you. Panel menus get renamed often, so hunt by content, not label: you need order-level rows with dates and tax splits, not a settlement summary. Download them on the 1st, before panels archive or restate anything.

GSTR-1 reports outward supplies by invoice date — for marketplace sellers, that is anchored to when the sale was invoiced, which follows the order, not the settlement. The settlement date is when money moved, weeks later, and building GSTR-1 from settlement reports drags last month's sales into this month's return. Pick the invoice-date basis, apply it identically to both marketplaces every month, and confirm the treatment once with your CA. The trap is not choosing wrong — it is mixing two bases in one filing.

Through credit notes, not by shrinking the sales figure. A return that reverses a sale gets a credit note entry in GSTR-1, which reduces your net taxable turnover and claws back the tax on that order. The month-end wrinkle: a sale from the 28th can return on the 5th, so each month you are typically reporting this month's sales plus credit notes for last month's stragglers. Keep the returns report from both panels and match each credit note to an original order so nothing is netted twice.

AJIO and Meesho each file GSTR-8, reporting your taxable sales and the 0.5% TCS withheld under section 52. Their filing surfaces on the GST portal (visible via your TCS/GSTR-2A view) for you to accept. The check is simple arithmetic: the turnover implied by their TCS should roughly equal the turnover in your GSTR-1 for that marketplace, allowing for timing differences around returns. If the gap is more than a rounding story, one of you is wrong — find out which before the department asks.

First, check the date basis — most gaps are timing: an order the marketplace counted in March that your file counted in April, or returns netted in different months. Second, check completeness: cancelled orders, RTOs, and multi-SKU sub-orders are the usual missing rows. If the difference is genuine and on the marketplace's side, raise it through seller support with order-level workings attached. If it is on yours, amend in the next period. What you should not do is ignore it — GSTR-8 versus GSTR-1 is a comparison the system runs, not one you can opt out of.

The painful half of GSTR-1 is not the filing — it is rebuilding a trustworthy order-level dataset from panel exports every month. Robnu already has that dataset, because it runs your AJIO and Meesho operations order by order: every sale, return, and deduction is captured as it happens and reconciled against settlements. Month-end becomes an export instead of an archaeology project — one consistent file across both marketplaces, returns matched to their original orders, ready for your CA to map into GSTR-1. Robnu prepares the truth; your CA files it.

Sources

Where this comes from

  • GSTR-1 return structure, credit-note treatment, and the TCS/GSTR-8 mechanism under section 52, CGST Act: gst.gov.in and cbic.gov.in. Due dates and table layouts change with notifications — confirm the current ones on the portal.
  • Meesho supplier panel and AJIO seller panel report documentation: supplier.meesho.com learning hub and AJIO seller support material.
  • Month-end cutoff and turnover-mismatch pain points: recurring seller reports in public community threads and CA commentary, 2024–2026. Illustrative figures are examples, not policy numbers.
build c3ffebc77e7004ab28f3be8d8e290923969592fe · 2026-07-08T12:37:42+05:30