Finance Compliance and Fraud Analytics

Every marketplace settlement in India involves a TDS deduction that the platform is legally required to make under Section 194-O of the Income Tax Act. Amazon, Flipkart, Nykaa, Meesho, and other platforms deduct TDS at 1% of the gross order value (or at a different applicable rate if PAN is not furnished) before remitting the settlement amount to the seller. This deduction is supposed to be reflected in Form 26AS and the Annual Information Statement (AIS) so that sellers can claim credit for it in their income tax return.

The problem is that TDS deductions in marketplace settlements are often misallocated, deducted at incorrect rates, or not reflected in Form 26AS on time. A brand selling across three platforms with 2,000 to 5,000 orders per month may have hundreds of TDS line items per settlement cycle, across multiple platforms, each with slightly different reporting formats. Manually reconciling these against Form 26AS at year-end is both error-prone and time-consuming, and late identification of discrepancies can result in tax credit shortfalls that affect cash flow.

FireAI automates TDS reconciliation by parsing settlement reports from every active marketplace and matching each TDS deduction line against the corresponding order, verifying the deduction rate, and tracking the aggregate TDS credit expected versus what has been reflected in Form 26AS.

What FireAI tracks for TDS deduction reconciliation:

• TDS deducted per settlement by platform: every settlement from every marketplace is parsed to extract the TDS deduction amount, the applicable rate, and the base transaction value on which TDS was computed. Any rate deviation from the applicable statutory rate is flagged
• Cumulative TDS credit position: across all platforms, what is the total TDS credit the brand should be able to claim for the current financial year to date? This figure is compared against what is currently reflected in Form 26AS to identify the gap
• Form 26AS match status: for each platform, are the TDS amounts being reported in Form 26AS matching the deductions made in settlement reports? Mismatches by platform and by quarter are surfaced for follow-up with the marketplace or a CA
• Rate discrepancy detection: instances where a marketplace has deducted TDS at a rate other than the applicable rate, such as deducting at 5% due to PAN not being matched in their system even though the seller's PAN is registered. These are recoverable through dispute or adjustment
• Month-wise TDS deduction trend: how much TDS is being deducted across all platforms in each month? Trend tracking helps finance teams estimate advance tax liability and plan cash flow accordingly
• Settlement-to-deduction lag: some platforms report TDS deductions in the settlement report of the month following the transaction month. FireAI tracks which platforms have a reporting lag and adjusts the credit reconciliation timeline accordingly

Real example: A skincare D2C brand selling on Amazon, Nykaa, and Meesho found through FireAI's TDS reconciliation that Meesho had been deducting TDS at 5% (non-PAN rate) for 4 months despite the seller's PAN being registered on the platform. The excess deduction across 4 months totalled ₹1.84 L. FireAI identified the mismatch by comparing the deduction rate in each settlement line against the expected 1% statutory rate. The brand raised a formal query with Meesho's seller support and received a credit note adjustment in the subsequent settlement. Without automated reconciliation, this discrepancy would likely have been discovered only at year-end during the tax filing review.

FireAI natural language queries:

• "What is our total TDS credit position across all platforms for this financial year?"
• "Are there any TDS rate discrepancies in the last 3 months of settlements?"
• "Show me the Form 26AS match status for each platform for Q3"

Returns are a structural feature of D2C marketplace commerce, not an edge case. Return rates of 15 to 30% are common in categories like apparel, beauty, and consumer electronics. Every return creates a GST adjustment obligation: the original supply transaction must be reversed or credited, and the GST collected on that supply must be adjusted in the corresponding return filing period. If returns are not correctly accounted for in GSTR-1 and GSTR-3B, the brand either overpays GST (failing to claim the credit for returned goods) or underpays (by incorrectly netting returns against new sales without the corresponding credit note documentation).

Marketplace settlement reports handle returns in inconsistent ways. Some platforms issue credit notes that clearly reverse the original invoice. Others net returns against new sales in the same settlement and report a single net figure. Some return transactions span two GST filing months, where the original sale was in March and the return and credit note are processed in April. Each of these scenarios creates a different GST adjustment treatment, and failing to handle them correctly creates a reconciliation gap between books and filings that accumulates over time.

FireAI reconciles GST on returns by parsing marketplace settlement data, matching return transactions to their original supply invoices, and verifying that the correct credit note has been issued and accounted for in the corresponding GST return period.

What FireAI tracks for GST on returns and adjustments:

• Return transaction matching: every return in every marketplace settlement is matched to its original supply invoice to verify the correct GST rate, invoice value, and tax amount that needs to be reversed
• Credit note issuance tracking: has a credit note been issued for each return? For platforms that issue credit notes automatically, FireAI verifies that the credit note data matches the return transaction amount and GST components. For platforms that net-settle, FireAI reconstructs the implicit credit note
• Cross-period return adjustments: returns where the original supply and the return fall in different GST filing periods are tracked separately because they require adjustment in the return period rather than offsetting in the original supply period
• GSTR-1 vs settlement reconciliation: the aggregate value of sales and credit notes reported in GSTR-1 should match the net revenue and return credits in the settlement reports. FireAI computes this reconciliation monthly and flags mismatches before filing
• ITC reversal on returns: for goods purchased with input tax credit that are subsequently returned by customers, the corresponding ITC reversal obligations are tracked and included in the GSTR-3B reconciliation
• Accumulated adjustment gap: the total GST adjustment amount that is pending correct accounting across all platforms and all open return transactions. A growing adjustment gap is a risk signal ahead of a GST audit

Real example: A D2C apparel brand with a 24% average return rate across Flipkart, Myntra, and Amazon was filing GSTR-1 based on its ERP's net sales figure, which automatically deducted return credit notes. FireAI's GST reconciliation found that 18% of the return credit notes from Myntra were being applied in the wrong GST period because Myntra's settlement cycle meant return credits appeared in the following month's settlement. Over 6 months, this created a ₹3.6 L GST mismatch between GSTR-1 filings and actual settlement data. The CA corrected the accounting treatment with a period-accurate credit note mapping, which resolved the mismatch and avoided a potential GST notice.

FireAI natural language queries:

• "What is the total GST adjustment pending from returns in the last 3 filing months?"
• "Are there any credit notes from returns that have not been reflected in the correct GST period?"
• "Show me the GSTR-1 vs settlement reconciliation gap for this quarter"

Each marketplace operates under a detailed and frequently updated seller policy framework that governs pricing, listing content, fulfillment SLAs, product authenticity claims, restricted category permissions, and advertising practices. Violations of these policies can result in listing suppression, seller rating degradation, account suspension, financial penalties, or loss of eligibility for programs like Amazon Prime or Flipkart Assured. In many cases, a breach is triggered by a platform algorithm before any human reviews it, and the seller learns about it only when their listing is already suppressed or their account has received a strike.

The challenge for a D2C brand managing hundreds of active listings across three to five marketplaces is that policy compliance cannot be monitored manually at scale. Price parity policies (requiring that the price on the marketplace does not exceed the price on your own website) are violated by a promotional campaign on one channel. Listing content policies are violated when a product description uploaded in bulk contains a restricted claim. Fulfillment SLA policies are violated when a logistics partner misses a dispatch window during a sale period. Each of these triggers a policy event that, if not resolved quickly, escalates from a warning to a penalty.

FireAI monitors policy compliance across all active marketplaces and listings by connecting seller account health data, listing status feeds, pricing data, and fulfillment performance records to flag active and potential policy breaches before they escalate.

What FireAI tracks for marketplace policy breach flagging:

• Account health score by platform: each marketplace publishes a seller account health score or equivalent metric based on policy compliance. FireAI tracks this score daily by platform and flags downward movements before they reach penalty thresholds
• Price parity monitoring: FireAI compares the active price of each SKU across all marketplaces and the brand's own D2C website to identify price parity violations. If a promotional price on the brand's website creates a parity breach with a higher price on a marketplace, FireAI flags it before the platform's automated system does
• Listing suppression alerts: any listing that transitions from active to suppressed, inactive, or restricted is immediately flagged with the reason code provided by the platform. FireAI clusters suppression reasons to identify systemic content or compliance issues affecting multiple listings simultaneously
• Fulfillment SLA breach tracking: order-level fulfillment performance is tracked against each platform's SLA requirements for dispatch time and delivery time. SLA breach rates approaching the platform's penalty threshold are flagged for logistics intervention
• Restricted claim detection: product descriptions and listing content are monitored for language that the platform classifies as restricted: health claims, competitive comparisons, or category-specific prohibited language. Flagging happens before the content is submitted so it can be corrected before triggering an automated violation
• Policy update alerts: when a marketplace announces a policy change that affects product categories or seller programs the brand participates in, FireAI flags the change and surfaces the affected listings for review

Real example: A D2C supplements brand running on Amazon and Flipkart discovered through FireAI's policy monitoring that a bulk listing update had introduced a health claim phrase in 14 product descriptions that violated Amazon's health supplement content policy. The listings had not yet been suppressed, but FireAI's content monitoring flagged the phrase across all 14 listings within 48 hours of the update. The brand corrected the descriptions before Amazon's automated review flagged them. A similar violation on 6 listings 3 months earlier had resulted in 11 days of suppression and an estimated ₹2.4 L in lost GMV before the listings were reinstated.

FireAI natural language queries:

• "Which of our listings are currently suppressed and what is the reason code?"
• "Are there any price parity violations across our active SKUs right now?"
• "Which platform's account health score has moved below the safe threshold this week?"

Fraudulent order behavior in D2C marketplaces takes several distinct forms. Return fraud is the most common: a customer receives a genuine product, returns a counterfeit or damaged item, and the seller's return authorization process credits them without inspecting the returned good. Coupon and promotional abuse involves buyers creating multiple accounts to claim first-order discounts or referral bonuses repeatedly. Competitor manipulation involves bulk purchases of a brand's inventory followed by immediate returns to suppress the brand's stock and seller rank. And triangulation fraud involves a customer placing an order with a stolen payment instrument and having it delivered to a third party before the chargeback occurs.

Each of these patterns is difficult to detect on a per-order basis because individual transactions look legitimate. The signal emerges at the pattern level: a cluster of orders from overlapping IP addresses, a cohort of buyers whose return rate is 8x the category average, a set of orders placed on consecutive days all using the same coupon code across different account IDs, or a spike in delivery refusals from a specific pin code cluster after a competitor's flash sale.

FireAI analyses order data, return records, customer identity signals, coupon redemption logs, and fulfillment outcome data to surface fraudulent order patterns at the cohort and cluster level, giving fraud teams and marketplace managers an early warning before promotional budget is eroded or seller ratings are impacted.

What FireAI tracks for fraudulent order pattern detection:

• High-return cohort identification: customers or customer clusters whose return rate is more than 3x the SKU-level category average over any 90-day window. These cohorts are flagged for review before new promotional codes are extended to them
• Coupon abuse detection: the same coupon code or promotion claimed by accounts sharing device fingerprints, delivery addresses, or IP ranges. FireAI detects this across multiple account IDs and flags suspicious redemption clusters
• Return quality anomalies: for categories with a quality check on returns, FireAI tracks the rejection rate of returned items by customer account and by marketplace. A customer with a high rate of returned items rejected at quality check is a return fraud risk flag
• Bulk order and cancel patterns: orders placed in large quantities followed by returns or cancellations within a short window, particularly from accounts with no purchase history, are flagged as potential inventory manipulation or competitor sabotage
• Delivery refusal clustering: orders where the recipient refused delivery (resulting in a return-to-origin) that cluster in specific pin codes or time windows, which can indicate organized fraud rather than individual buyer remorse
• Chargeback rate tracking: by platform and payment method, what is the chargeback rate and what is the overlap with previously flagged high-return accounts? Accounts with both high returns and a chargeback history are highest priority for restriction

FireAI natural language queries:

• "Which customer accounts have a return rate more than 3x the category average in the last 90 days?"
• "Are there any coupon codes being claimed across multiple accounts sharing the same delivery address?"
• "Show me any bulk order and cancel patterns from new accounts in the last 30 days"