Amazon, Flipkart & Meesho Invoices to GSTR-1

By the 8th of the month, a marketplace seller may already have Amazon MTR, a Flipkart Sales Report, a Meesho TCS report, and a folder of buyer-requested B2B tax invoice PDFs waiting for review. For a monthly filer, the 11th is close enough that the workflow has to separate usable report data from documents that still need extraction.

For Amazon, Flipkart, and Meesho sellers, the practical GSTR-1 workflow is not to run OCR on every file. Use the native marketplace reports where they are already Excel or CSV, then extract per-order PDF tax invoices where the report is missing detail, where a buyer-requested B2B invoice needs checking, or where the source document must be kept ready for audit support.

The target is one GSTR-1-ready workbook. Each row should carry the marketplace, order ID, invoice number, invoice date, buyer GSTIN, place of supply, HSN or SAC, taxable value, IGST or CGST and SGST, TCS deducted if applicable, return or credit-note reference, and the target GSTR-1 table. That is the practical meaning of moving Amazon Flipkart Meesho invoices to GSTR-1: not a pile of downloaded files, but a reviewed dataset that can survive filing checks and later questions.

For a multi-marketplace seller, the month-end bundle usually looks like this:

• Amazon Merchant Tax Report or MTR, with B2B and B2C data depending on the report variant.
• Flipkart Sales Report or tax report, usually with its own order and invoice identifiers.
• Meesho TCS, tax invoice, or sales report, often focused on tax collected at source and platform deductions.
• Extra exports from Myntra, Paytm Mall, JioMart, or another marketplace if the seller lists beyond the big three.
• PDF tax invoices issued by the marketplace, especially where the buyer asked for an invoice with GSTIN or where a report row needs document-level proof.

The mistake is to treat all of these files as the same kind of input. A report that already opens cleanly in Excel should be mapped, cleaned, and validated. A PDF invoice should be extracted into the same column structure so it can be compared against the report rows. If those two jobs are mixed together, the workbook becomes difficult to trace: some rows come from platform exports, some from invoice documents, and nobody can tell which source supports which figure.

The pressure is highest near the GSTR-1 due date because outward supplies, returns, credit notes, TCS, and GSTIN-level checks all have to agree well enough for review. The article below keeps the workflow Excel-first, because many sellers and bookkeepers still want a master workbook before they use the GSTN offline tool, a filing utility, or their accountant's preferred software.

Separate native reports from invoices that still need extraction

Amazon MTR to GSTR-1 reconciliation starts with the MTR itself, not with the invoice PDFs. The Merchant Tax Report is already a structured export, so the work is to identify the columns that map to your GSTR-1 workbook: order ID, invoice number, invoice date, buyer GSTIN where present, taxable value, tax split, place of supply, and return adjustments. The awkward part is that Amazon's B2B and B2C reporting view does not always line up with the way a seller wants to review GSTR-1 rows.

Flipkart creates the same kind of problem in a different schema. A Flipkart Sales Report to GSTR-1 Excel workflow has to normalise Flipkart's order identifiers, invoice references, tax columns, cancellations, and returns into the same columns used for Amazon. If the seller also downloads individual Flipkart tax invoice PDFs, those documents should support or fill gaps in the report, not replace the report where the report is complete.

Meesho adds another layer because the Meesho TCS report tax invoice extraction problem is partly about tax collected at source. The TCS figure may sit in a report that is separate from the invoice evidence the seller wants to keep. If the seller only copies sales totals, the TCS trail gets detached from the outward supply row and becomes harder to explain later.

This is why a vendor-neutral workflow should separate inputs into two groups:

• Native reports: Amazon MTR, Flipkart sales or tax reports, Meesho TCS or tax reports, and similar Excel or CSV exports. These should be imported, renamed, typed, and mapped.
• Document evidence: Marketplace-issued PDF tax invoices, buyer-requested B2B invoices, historical invoice downloads, scans, and incomplete report cases. These should be extracted into the same schema as the native reports.

Full marketplace GST platforms can be the right answer for larger sellers that want connectors, reconciliation dashboards, and filing workflows. The Excel-first path serves a different reader: a seller, bookkeeper, or CA office that wants to consolidate Amazon, Flipkart, and Meesho invoices for GST filing without moving the whole process into a subscription platform.

Build one normalised schema before mapping GSTR-1 tables

The master workbook is the control point. Without a normalised schema, each platform remains its own island: Amazon uses one set of column labels, Flipkart another, Meesho another, and invoice PDFs carry the same facts in document form rather than table form. The workbook should make the tax meaning consistent before anyone thinks about upload formats.

A useful schema for marketplace seller GSTR-1 from invoice PDFs and reports should include:

• Marketplace
• Seller GSTIN, if the business files under more than one registration
• Order ID
• Invoice number
• Invoice date
• Buyer GSTIN
• Buyer state or place of supply
• B2B, B2CL, or B2CS classification
• HSN or SAC
• Item description
• Quantity
• Taxable value
• IGST
• CGST
• SGST
• Cess, where relevant
• TCS deducted
• Return or credit-note reference
• Source file
• Source page
• Target GSTR-1 table

The source columns are not just audit decoration. If a row came from Amazon MTR, the source may be the report name and sheet. If a row came from a Flipkart invoice PDF, the source file and page let the bookkeeper reopen the exact document when a buyer GSTIN, HSN, invoice number, or tax split does not match the report. That matters when someone later asks why a row was classified as B2B rather than B2C, or why a credit note was linked to a particular invoice.

Invoice-level extraction is enough when each document maps to one tax row. Line-item extraction is better when HSN, quantity, rate, or tax split must be reviewed below the invoice header. For marketplace sellers with mixed products, line-item data also helps catch cases where a report total looks right but the HSN summary is not ready for review.

Excel typing is part of the schema, not an afterthought. GSTINs and invoice numbers should be text so leading zeros, suffixes, and long identifiers are not altered. Dates should use one stable format. Taxable values and tax amounts should remain numeric so totals, pivot tables, and exception checks work. If a seller is trying to convert an archived Amazon merchant tax report PDF to Excel in India, or run Flipkart seller invoice OCR on old downloads, the extracted rows still need to land in this same schema.

Invoice Data Extraction fits this layer when the input is a batch of PDF invoices or images rather than a native report. A user can upload the invoice files, describe the exact GSTR-1-ready columns they want, and download Excel, CSV, or JSON rows. For review work, the useful part is not only the extracted fields; it is that each output row can reference the source file and page used to produce it.

Route B2B, B2CL, and B2CS rows correctly

The workbook is only GSTR-1-ready when every outward supply row has a table target. For marketplace sellers, the first split is usually buyer GSTIN. If the buyer GSTIN is present and valid, the row generally belongs in the B2B section for registered-recipient supplies. This is why buyer-requested B2B invoice PDFs deserve special attention: a missing or mistyped GSTIN can move the row into the wrong review path.

For consumer sales, the place of supply and invoice value decide whether the row is B2CL or B2CS. From the August 2024 return period, B2CL covers inter-state taxable outward supplies to consumers where the invoice value is more than INR 1 lakh. B2CS covers intra-state consumer supplies and inter-state consumer supplies at or below that threshold. In working terms: find the buyer status, place of supply, and invoice value before assigning the table.

GSTN's Returns Offline Tool supports this Excel-first workflow. The GSTN Returns Offline Tool user manual states that taxpayers can prepare FORM GSTR-1/IFF by importing an Excel workbook, importing CSV files, copying data from Excel, or manually entering invoice data, and that its multi-sheet Excel workbook includes sections for B2B, B2CL, and B2CS supplies.

That does not mean any spreadsheet is ready for filing. The GST portal and offline tool still validate the data. Marketplace rows need enough detail to survive those checks: invoice number, invoice date, recipient GSTIN where applicable, place of supply, taxable value, tax rate, and tax split. When a PDF invoice is the supporting source, the extracted row should preserve the fields that an Indian GST tax invoice is expected to carry; the companion guide to India GST invoice requirements under Rule 46 is useful when checking which invoice fields belong in the evidence file.

The table routing should be visible in the workbook, not left as a filing-time judgement. Add a target table column and populate it before upload or handoff. Then the reviewer can filter all B2B rows with missing GSTINs, all B2CL rows near the threshold, and all B2CS rows with inter-state supplies to confirm that the classification logic has been applied consistently.

Treat TCS, returns, and credit notes as a reconciliation trail

Marketplace TCS should not be treated as a spare column added after sales totals are complete. For e-commerce sellers, TCS connects the platform's reporting, the seller's GST records, and the evidence available for month-end review. The marketplace operator collects TCS at the applicable GST rate on eligible net taxable supplies and reports it through GSTR-8, so the seller should reconcile those TCS rows back to outward-supply rows before month-end review. If a Meesho TCS report shows tax collected at source but the seller's master workbook has no matching outward supply row, the reviewer has a reconciliation problem, not a formatting problem.

The same logic applies to returns and credit notes. A returned order should link back to the original order ID or invoice number. A credit note should carry its own date and reference, plus enough detail to explain which sale it adjusts. If the marketplace report shows net movement but the invoice folder contains the original tax invoice and a later credit note, the workbook should preserve both sides of that trail.

Useful checks include:

• Duplicate invoice numbers within the filing period.
• Cancelled orders that still appear in a sales report.
• Returned orders without a linked invoice or credit note.
• Credit notes dated in a different period from the original invoice.
• Place-of-supply mismatches between the report and the invoice.
• TCS rows with no corresponding outward supply row.
• B2B rows where the buyer GSTIN appears in one source but not another.

This article is about outward-supply preparation, but GSTR-2B review still matters to the same month-end discipline. Sellers and accountants reviewing inward supplies, ITC, IMS, and GSTR-2B should use the dedicated guide to India GST ITC reconciliation with GSTR-2B and IMS. The connection here is evidential: if outward supplies, marketplace reports, TCS, returns, and credit notes are not traceable, the month-end file becomes harder to defend when another part of the GST workflow raises a mismatch.

Use PDF extraction for the invoice layer, not as a replacement for marketplace reports

Keep the native reports as the source for the fields they already provide cleanly. If Amazon MTR, a Flipkart report, or a Meesho export already gives a structured column, use that report as the starting point and map it into the master workbook. Do not convert a good Excel file into a PDF extraction problem.

Use extraction where the evidence is actually document-shaped: marketplace-issued PDF tax invoices, scanned historical invoices, buyer-requested B2B invoices, mixed invoice folders, and cases where the report row needs to be checked against the source document. That is the natural place for invoice data extraction for marketplace tax invoices, because the job is to turn invoice documents into structured rows that can sit beside the platform reports.

For a GSTR-1 workbook, the prompt should name the columns the seller needs rather than asking for a generic invoice summary. A practical extraction instruction would ask for invoice number, invoice date, order ID, buyer GSTIN, place of supply, HSN or SAC, item description, quantity, taxable value, IGST, CGST, SGST, TCS if visible, credit-note reference, source file, and source page. For line-item invoices, ask for one row per line item and repeat the invoice-level fields on each row.

Invoice Data Extraction supports PDF, JPG, and PNG inputs, including batches of up to 6000 files and individual PDFs up to 5000 pages. The output can be Excel, CSV, or JSON. The prompt is the configuration, so a seller or bookkeeper can specify field names, column order, date formats, default values, credit-note handling, and other extraction rules in natural language. Repeat users can save prompts for recurring workflows.

The boundary is important. The tool does not file GSTR-1, connect to Amazon or Flipkart, generate GST portal JSON, or reconcile settlements. It prepares structured data from invoice documents. The review, table routing, portal upload, and filing judgement still sit with the seller, bookkeeper, CA, GSTN offline tool, or filing software.

Review the workbook before upload or accounting import

Before the workbook goes into the GSTN offline tool, filing software, or a CA handoff folder, review it as a tax dataset rather than as a data-entry output. The common failures are small enough to hide in a spreadsheet but serious enough to create filing errors.

Check the required fields first: invoice number, invoice date, buyer GSTIN where applicable, place of supply, taxable value, tax rate, tax split, HSN or SAC, and target GSTR-1 table. GSTINs and invoice numbers should still be text. Dates should use one format. Tax values should add back to the invoice totals within the rounding tolerance the reviewer accepts.

Then check the marketplace-specific issues. Filter for duplicate invoice numbers, cancelled orders, returned orders without credit-note links, B2B rows missing buyer GSTIN, B2CL rows at or near the INR 1 lakh threshold, and TCS entries that do not match an outward supply row. For every row produced from PDF extraction, confirm that the source file and page are present so the document can be reopened during review.

Some sellers will use the workbook only for GSTR-1 preparation. Others will bring the same normalised data into accounting software so sales, tax, returns, and credit notes are reflected in the books. If that is part of the month-end process, the guide to importing invoice data into TallyPrime covers the accounting import side separately.

The standard is straightforward: a reviewer should be able to pick any row, identify the marketplace and source document, see why it belongs in its GSTR-1 table, recalculate the tax split, and trace any return or credit note back to the original sale.