Marg ERP: Getting Invoice Data Out for Claim Reconciliation

A scheme or claim settlement needs invoice-level evidence regardless of which system produced the invoice. Marg, like most Indian accounting and billing systems, can export sales and purchase data to Excel or CSV — what matters is exporting the right fields, consistently, for the right period.

The field a claim needs	Why it matters
Invoice number and date	Identifies the transaction and places it in a scheme period
Party name and GSTIN	Identifies the counterparty unambiguously across months
Item / product code	Applies the scheme's product scope reliably
Batch and expiry	Decides eligibility for expiry, breakage and damage claims — batch-level, not product-level
Quantity (with unit of measure)	Drives quantity-based schemes
Rate and taxable value	Drives value-based schemes and rate-difference claims
Tax amount and rate	Needed when settlement runs through a credit note
Document type — sales, purchase or credit note	Determines which side of the claim the row evidences, and whether it nets off

What a claim needs from your billing data

The question a claim settlement answers is narrow: which transactions qualify, at what value, in what period? Everything in the table above exists to answer it without a phone call.

For a distributor claiming from a company, the primary evidence is purchases — what was bought, when, from whom, at what value. Schemes rewarding onward movement additionally need sales data. And in pharma and agri-input distribution specifically, a large share of claims are not volume schemes at all but returns: expiry, breakage, damage. Those are decided per batch, which changes what the export must carry.

The general specification is in the invoice upload file, field by field. What follows is what pharma and agri distribution add to it.

Exporting the data

Indian billing and accounting systems generally allow registers — sales, purchase, credit notes — to be exported to Excel or CSV. The choices you make are the same in any of them: the date range, the register, and the columns.

This article gives no menu paths or step sequences deliberately. Exact steps, option names and available columns vary by version and by how your setup is configured, so instructions correct for one installation mislead in another. Follow your own system's export function, or ask your vendor or accountant — they know your configuration.

What deserves your attention is not the sequence of clicks but whether the export contains batch data, whether it carries GSTIN, and whether it looks the same next month as it did this month.

Pharma-specific fields: batch and expiry

This is where a pharma or agri-input export differs from a general FMCG one, and where most claim failures in these sectors originate.

Eligibility is a batch-level fact. Whether an expiry return qualifies depends on that specific batch's expiry date, whether the claimant actually purchased that batch, and whether the return falls inside the policy window. A product code cannot answer any of those questions. A file without batch detail therefore makes expiry claims unverifiable — they get settled on trust, disputed, or held.

Batch also prevents a specific failure: goods returned that the claimant never bought from you, or bought in a quantity smaller than the return claims. Matching the claimed batch against billing history is the check that catches it, and it needs batch numbers on both sides.

The settlement treatment of these returns — including the GST position on pharma claims and returns and credit notes for expired and damaged goods — depends on the same batch evidence, so the export feeds both the validation and the documentation. The wider return process is covered in pharma expiry, breakage and returns.

Consistency is what makes it reconcile

Same columns, same order, same date convention, same party naming, every period.

Inconsistency between one month's file and the next causes more failed uploads than any technical fault. It creeps in innocently: a different person runs the export, a column looks useful and gets added, someone widens the date range "to be safe" and quietly double-counts a fortnight.

Two habits prevent most of it — save the export configuration rather than rebuilding it monthly, and note the row count and value total before sending so the receiving side can confirm nothing was truncated. The party and product foundations underneath are in master data hygiene.

From export to settled claim

Export the register for the period, upload it, match it against the scheme's terms and the party and product masters, and produce the claim with its evidence attached.

ClaimDS takes invoice data as Excel or CSV, validates it against the rebate agreement's terms and the invoice-level base data, checks claimed batches against billing history for return claims, and flags exception lines for review rather than failing the whole file. It runs alongside whatever system you bill from — a file-based exchange, not a replacement — and settlements come back out as a file to post into your books. The wider picture is in connected claims.

To check your own export against what a claims workflow needs, book a demo.

Note: General information about data export for claim settlement. This article makes no claim about what any particular version of any billing or accounting product does — steps and capabilities vary by version and configuration. Check your own system's documentation or ask your vendor.