Binarysoft is Authorised Tally Sales & Implementation Partner in India
+91 742 877 9101 or E-mail: tally@binarysoft.com 10:00 am – 6: 00 pm , Mon-Fri
Call CA Tally HelpDesk +91 9205471661, 7428779101
In 2026, Amazon sellers in Bawana Industrial Area and Narela Industrial Area are managing increasingly complex accounting data across B2B and B2C sales, returns, cancellations, marketplace fees, shipping charges, GST, TCS/TDS-related entries where applicable, and settlement deductions. The pressure is no longer simply to record Amazon orders in TallyPrime; businesses need their sales, receivables, deductions, refunds and actual bank settlements to reconcile correctly. Manually entering hundreds or thousands of marketplace transactions can create mismatches between Amazon reports, GST records, TallyPrime ledgers and bank receipts. A structured Amazon-to-TallyPrime import workflow can reduce repetitive entry by converting marketplace reports into properly mapped accounting data. For manufacturers, wholesalers, distributors and online sellers, the benefit is greater control: faster bookkeeping, clearer settlement reconciliation, better visibility of marketplace charges and more reliable GST-related records before return preparation and financial closing.
Selling through Amazon can expand a business far beyond its local market. A manufacturer in Bawana Industrial Area can sell goods to customers throughout India, while a distributor operating from Narela Industrial Area can manage thousands of marketplace orders without opening physical stores in every state.
But growth in orders creates growth in accounting complexity.
An Amazon seller may see hundreds of orders on the marketplace dashboard, but the amount finally received in the bank is generally not the simple total of those orders.
There may be various components involved, such as sales, customer refunds, marketplace fees, shipping-related charges, commissions, taxes on applicable charges, adjustments, recoveries and other settlement components.
This is why Amazon accounting should not be treated as:
Amazon Sales = Bank Receipt
Instead, businesses need a workflow that connects:
Amazon Orders
→ Sales Accounting
→ GST Classification
→ Returns and Credit Notes
→ Amazon Fees and Deductions
→ Settlement Reconciliation
→ Bank Receipt
→ TallyPrime Accounting
The objective is to understand every major component between the original sale and the final settlement.
Bawana Industrial Area and Narela Industrial Area are important manufacturing and industrial zones in Delhi. Businesses operating from these locations may manufacture or trade products such as electrical goods, household products, packaging materials, garments, plastic products, machinery components, consumer products, furniture accessories and numerous other categories.
For a traditional wholesale business, an accountant might process a manageable number of invoices every day.
E-commerce changes that scale.
Instead of 20 large wholesale invoices, the business may receive 500 smaller marketplace orders.
The total sales value may be similar, but the accounting workload can increase dramatically.
Every transaction can carry information such as:
Invoice number
Order number
Invoice date
Customer type
Place of supply
GSTIN where applicable
Product details
HSN code
Taxable value
GST rate
CGST
SGST
IGST
Shipping-related information
Returns
Refunds
Marketplace deductions
Entering all this manually creates a substantial administrative burden.
Consider a fictional manufacturer based in Bawana Industrial Area.
The company had successfully expanded its product range to Amazon. Orders increased month after month, and the owner was pleased to see sales growing.
But the accounting team faced a different reality.
At the end of one settlement cycle, the Amazon reports showed substantial sales, while the amount credited to the bank was significantly lower.
The owner asked a simple question:
“Where has the remaining money gone?”
The accountant opened several spreadsheets.
One report contained orders. Another contained returns. A different statement showed marketplace charges. The bank statement showed only the net settlement amount.
For hours, the team moved between Excel sheets, calculator windows and TallyPrime.
Every figure seemed reasonable individually, but the settlement still did not reconcile.
The problem was not necessarily missing money. The problem was that sales, deductions, refunds and settlements had not been brought together in one structured accounting workflow.
The business then reorganized its process.
Amazon reports were standardized. Sales were separated from settlement data. Returns were identified. Marketplace deductions were classified into appropriate accounting heads. Settlement references were mapped, and bank receipts were reconciled against the corresponding settlement information.
For the owner, the biggest benefit was clarity.
Instead of asking, “Why did Amazon pay us less?” the team could explain how the gross transaction activity moved through deductions and adjustments to arrive at the net settlement.
That is the real purpose of Amazon settlement accounting.
Amazon sales import into TallyPrime is a structured process in which transaction information obtained from Amazon reports is transformed and mapped into the accounting structure required in TallyPrime.
The exact workflow depends on the Amazon reports available, the seller’s accounting requirements, the TallyPrime configuration and the integration or import method being used.
The objective is to reduce manual data entry while maintaining accurate accounting classifications.
Amazon data may need to be converted into information relating to:
Sales vouchers
Party or customer ledgers
Stock items
GST ledgers
Sales returns
Credit notes
Marketplace expense ledgers
Settlement or clearing accounts
Bank receipts
The process therefore involves much more than copying an Excel file into accounting software.
A settlement represents the financial movement through which marketplace transaction activity is ultimately reflected in the amount payable or paid to the seller.
The accounting challenge is that the settlement amount may represent multiple underlying components.
A simplified illustration could look like this:
Gross Sales: ₹5,00,000
Less Customer Refunds: ₹25,000
Less Marketplace Fees and Other Applicable Charges: ₹45,000
Less Other Adjustments: ₹5,000
Illustrative Net Settlement: ₹4,25,000
These numbers are only an example.
Actual settlement components depend on the seller's transactions, Amazon's applicable charges, refunds, adjustments and the relevant reporting period.
The accounting system should therefore explain how the gross activity ultimately reconciles to the net amount received.
This is one of the most important concepts for marketplace accounting.
Suppose an Amazon seller generates ₹10 lakh in gross transaction value during a period.
It does not necessarily mean ₹10 lakh will appear as one bank credit.
There may be:
Refunds
Marketplace fees
Shipping-related charges
Adjustments
Taxes on applicable service charges
Other deductions or credits
Timing differences
Therefore, simply passing a bank entry as sales can produce inaccurate accounting.
Sales should be accounted for based on the relevant transaction and tax information, while the settlement should be reconciled separately.
B2B transactions generally require additional customer and GST information compared with ordinary consumer sales.
Depending on the transaction, businesses may need to capture:
Buyer GSTIN
Invoice number
Invoice date
Place of supply
Taxable value
GST rate
CGST
SGST
IGST
HSN/SAC information where applicable
Correct B2B classification is important because the accounting records should align with the underlying tax invoice and applicable GST reporting requirements.
Before importing B2B Amazon transactions, sellers should carefully validate GSTIN and place-of-supply information available in their source records.
B2C marketplace sales can involve significantly larger transaction volumes.
A seller may generate hundreds or thousands of consumer invoices.
The challenge therefore shifts from individual voucher entry to structured bulk processing.
A reliable import process should consider:
Invoice numbering
Invoice dates
Product information
Taxable amounts
GST rates
Place of supply
Tax components
Invoice totals
The data should also be organized in a manner suitable for the seller's accounting and GST reporting configuration.
GST classification can depend on the nature and place of the transaction.
For applicable intra-state supplies, CGST and SGST are generally relevant, while applicable inter-state supplies generally involve IGST.
For example, a Delhi seller supplying within Delhi may have a different tax structure from a Delhi seller supplying to a customer in another state.
Amazon sellers therefore need reliable place-of-supply information.
Incorrect state mapping can affect:
GST classification
Tax ledger allocation
GST reports
Reconciliation
Return preparation
Tax treatment should be reviewed according to the facts of each transaction and current GST requirements.
Begin with the relevant transaction and settlement reports available for the accounting period.
Depending on the seller's requirements, different reports may be needed to understand:
Orders
Invoices
Returns
Refunds
Fees
Adjustments
Settlements
Do not assume one spreadsheet contains every piece of information required for complete accounting.
Clearly define the period being processed.
For example:
1 September 2026 to 30 September 2026
Using controlled accounting periods makes reconciliation easier.
It also helps prevent the same transactions from being imported twice.
Raw marketplace reports are usually designed for marketplace reporting rather than direct accounting entry.
Before import, data may need to be cleaned and transformed.
Check:
Blank rows
Duplicate records
Cancelled transactions
Returns
Incorrect dates
Missing invoice numbers
Unwanted columns
Incorrect numeric formatting
Product naming differences
State information
GST-related fields
Only validated records should move to the accounting-import stage.
Amazon may identify a product using marketplace-specific information or a seller SKU.
TallyPrime may contain a different stock-item name.
For example:
Amazon SKU:
BC-STEEL-BOTTLE-1L-BLK
TallyPrime Stock Item:
Steel Water Bottle 1 Litre Black
A mapping table can connect the two.
A typical mapping structure may contain:
Amazon SKU
Product Name
TallyPrime Stock Item
HSN
GST Rate
Unit
Once maintained properly, this mapping can support repeated imports.
Different types of transactions may need different sales-ledger treatment depending on the company's accounting design.
A business may maintain separate ledgers for different tax categories, transaction types or business requirements.
The correct structure should be determined before bulk processing.
Do not create unnecessary ledgers simply because the Amazon report contains numerous transaction labels.
The accounting structure should remain understandable and manageable.
Before creating accounting entries, review:
GSTIN where applicable
Place of supply
HSN/SAC
Taxable value
GST rate
CGST
SGST
IGST
Invoice value
Where source data and calculated tax values differ, investigate the reason before importing a large batch.
After validation and mapping, sales information can be transformed into the required TallyPrime voucher structure.
The resulting transaction should correctly represent the accounting and inventory impact intended by the business.
A sales transaction may include:
Sales ledger
Customer or configured party ledger
Stock item
Quantity
Rate
Taxable value
GST ledger allocation
Invoice number
Invoice date
Narration or reference
Returns are a major part of marketplace accounting.
Suppose a customer purchases a product for ₹2,000 and subsequently returns it.
If the original sale remains recorded but the return is not accounted for, several reports may become inaccurate.
These can include:
Net sales
Customer or marketplace balance
GST-related records
Inventory
Profitability
Therefore, returns should form part of the complete import workflow.
Depending on the circumstances and accounting treatment, the transaction may require an appropriate credit note or other relevant entry.
Amazon-related deductions should not automatically be treated as reductions in sales.
Depending on their nature and applicable accounting/tax treatment, different charges may need separate expense or other relevant ledger classifications.
A business may maintain accounting heads for items such as:
Marketplace commission
Fulfilment-related charges
Shipping-related fees
Storage-related charges
Advertising expenses
Other marketplace service charges
The actual ledger structure should correspond with the charges appearing in the reports and the business's accounting policy.
Where GST is charged on marketplace services, the invoice and tax treatment should be recorded appropriately based on applicable GST rules and supporting documentation.
Businesses should not determine input tax credit merely from a settlement deduction.
Relevant tax invoices, eligibility conditions and GST records should also be reviewed.
For tax positions specific to a business, professional advice from a qualified tax adviser or Chartered Accountant may be appropriate.
Marketplace settlements may include tax-related deductions or collections that require separate accounting treatment where applicable.
These should not simply disappear into a general Amazon expense ledger.
Where relevant, businesses should identify the nature of the amount, supporting statement and applicable tax provision before deciding the accounting ledger.
This improves reconciliation and makes subsequent tax-related verification easier.
A useful accounting design may involve an Amazon clearing or settlement ledger.
Instead of expecting every sale to directly equal a bank receipt, transaction activity can first flow through a clearing account.
Conceptually:
Sales Transactions
↓
Amazon Clearing / Receivable
↓
Fees, Refunds and Adjustments
↓
Settlement Amount
↓
Bank
This provides visibility into the difference between gross marketplace activity and the actual amount received.
After sales and related components are processed, settlement data can be mapped.
The settlement information may contain:
Settlement ID
Settlement period
Transaction references
Credits
Deductions
Adjustments
Net settlement amount
The exact fields depend on the reports being used.
Settlement IDs are especially valuable because they provide a reference for reconciliation.
The final stage is bank reconciliation.
Suppose the calculated Amazon settlement is:
₹4,25,000
The corresponding bank statement should contain the related receipt, subject to timing and other applicable differences.
The accounting team should match:
Settlement ID
Settlement date
Settlement amount
Bank credit
Accounting entry
If the figures do not match, investigate the difference rather than forcing the accounts to balance.
Consider the following illustrative scenario:
| Component | Amount |
|---|---|
| Gross Sales Activity | ₹8,00,000 |
| Less: Returns/Refunds | ₹40,000 |
| Less: Marketplace Charges | ₹65,000 |
| Less: Other Adjustments | ₹10,000 |
| Illustrative Net Settlement | ₹6,85,000 |
The ₹6,85,000 bank receipt does not mean sales were only ₹6,85,000.
The underlying gross sales and the individual deductions need to be classified appropriately.
This distinction is essential for meaningful accounting.
Suppose Amazon deposits ₹6,85,000.
If the accountant records:
Bank Dr. ₹6,85,000
Sales Cr. ₹6,85,000
important information may be omitted.
The accounts may fail to separately reflect the gross sales and relevant returns, expenses, taxes or adjustments.
This can distort:
Revenue reporting
Expense analysis
GST reconciliation
Profitability
Marketplace cost analysis
A settlement reconciliation workflow provides a more transparent view.
For manufacturers and traders, marketplace accounting is not limited to financial vouchers.
Inventory must also be considered.
Each completed sale may affect stock based on the company's inventory configuration.
The import workflow may therefore need:
Amazon SKU
TallyPrime stock item
Quantity
Unit
Godown
Batch details where applicable
Rate
Inventory value
Without correct inventory mapping, sales totals may appear correct while stock reports remain inaccurate.
Returned goods require careful treatment.
Not every marketplace return necessarily has the same inventory outcome.
A returned product might be:
Returned to usable stock
Damaged
Lost in transit
Replaced
Disposed of
Held in a fulfilment location
The accounting and inventory treatment should reflect what actually happened to the goods.
Automatically adding every return back into saleable stock without checking its status can create false inventory.
Manufacturers in Bawana and Narela may have their own internal product codes.
For example:
Internal Code: FG-1024
Amazon SKU: AMZ-BLK-1024
TallyPrime Item: Finished Product Black Model 1024
A centralized SKU mapping table helps connect these identifiers.
The mapping should be reviewed whenever new products are added to Amazon.
Importing the same period twice can duplicate accounting entries.
Maintain transaction-level identifiers and import history.
Incorrect place-of-supply information can result in incorrect CGST/SGST/IGST classification.
An unidentified Amazon SKU may prevent correct inventory allocation.
Sales may be imported while refunds or returns are ignored.
This overstates net sales.
Combining every deduction into one expense ledger reduces reporting visibility.
A bank receipt may not match gross sales because the settlement contains several adjustments.
Orders, invoices, refunds and settlements can occur on different dates.
Businesses should establish a consistent accounting policy for the appropriate recognition and reconciliation dates.
Imagine a seller processing 2,500 transactions every month.
If manual entry and verification require even two minutes per transaction:
2,500 × 2 minutes = 5,000 minutes
That is more than 83 hours of work.
Automation does not eliminate the need for review, but it can shift those hours away from repetitive typing and toward:
Exception handling
GST reconciliation
Settlement verification
Inventory checking
Profit analysis
Receivable management
This is where automation creates practical value.
The ideal frequency depends on transaction volume.
Low-volume sellers may be comfortable with periodic processing.
High-volume sellers may benefit from more frequent imports.
Daily or weekly processing can make errors easier to identify because fewer transactions need to be investigated at once.
Waiting until the end of the financial year to reconcile thousands of marketplace transactions can create unnecessary pressure.
A seller may celebrate ₹20 lakh in monthly marketplace sales.
But sales alone do not show actual profitability.
Management may also need to understand:
Cost of goods sold
Marketplace commission
Fulfilment expenses
Shipping costs
Advertising expenditure
Returns
Damaged inventory
Other platform-related charges
When these components are properly classified, TallyPrime can provide a more useful financial picture.
The question changes from:
“How much did we sell on Amazon?”
to:
“What did we actually earn from those sales?”
Before closing an Amazon accounting period, verify that:
Sales transactions are accounted for
B2B and B2C transactions are appropriately classified
GST information has been reviewed
Returns and refunds are accounted for
Marketplace charges are classified
Relevant tax components are reviewed
Settlement IDs are recorded where required
Bank receipts are matched
SKU mapping is complete
Inventory impact is checked
Duplicate transactions are identified
Failed import records are reviewed
Differences are investigated
A reconciliation checklist can prevent small errors from becoming year-end problems.
Before processing any large marketplace report, maintain a controlled workflow:
Raw Amazon Report
→ Preserve Original Copy
→ Working Copy
→ Clean Data
→ Validate Fields
→ Map Masters
→ Generate Import Data
→ Test Import
→ Reconcile
→ Full Import
Never modify the only available copy of the original report.
Maintaining the raw source file helps when differences need to be investigated later.
Do not begin with thousands of transactions.
Select a controlled sample that includes:
B2B invoice
B2C invoice
Local sale
Inter-state sale
Return
Refund
Multiple GST rates where applicable
Different products
Different states
Import the sample and review the results.
Only proceed after confirming that the accounting outcome matches the intended treatment.
Maintain an appropriate backup of TallyPrime company data before significant bulk processing.
This is particularly important when an import affects:
Sales vouchers
Credit notes
GST ledgers
Inventory
Marketplace clearing accounts
Bank transactions
A backup provides an important recovery point if mapping or configuration needs correction.
Bawana-based manufacturers selling directly on Amazon may need to integrate three major workflows:
Manufacturing
Inventory
Marketplace sales
Their accounting cycle may look like:
Raw Material
→ Production
→ Finished Goods
→ Amazon Order
→ Sales Invoice
→ Inventory Reduction
→ Amazon Settlement
→ Bank Receipt
If only the Amazon sales value is imported, management may not receive the complete operational picture.
Inventory and production records should also be maintained according to the business's requirements.
A Narela-based distributor may purchase goods in bulk and sell through several channels:
Wholesale dealers
Retail customers
Amazon
Other marketplaces
Direct online orders
TallyPrime can serve as the central accounting system, but channel-wise data needs appropriate classification.
This can help management compare:
Amazon sales
Offline sales
Marketplace costs
Product margins
Returns
Inventory movement
Channel-wise accounting can provide better visibility than combining every transaction without meaningful classification.
Without automation, month-end may involve:
Downloading spreadsheets
Entering invoices
Finding missing transactions
Checking GST
Entering returns
Recording fees
Matching settlements
Matching bank credits
With a structured import workflow, much of the repetitive transformation can be standardized.
The accounts team can then concentrate on exceptions.
This changes the role of accounting from data entry to data verification.
A strong automated process should not silently ignore problematic records.
It should identify exceptions.
For example:
Invoice 1028 – Missing GSTIN
Invoice 1045 – SKU not mapped
Invoice 1061 – Invalid state
Invoice 1082 – Duplicate transaction
Invoice 1095 – Tax value mismatch
An exception report allows the accountant to correct only the problematic transactions instead of reviewing the entire dataset manually.
Marketplace reports can contain commercially sensitive information.
Businesses should maintain appropriate controls over:
Customer information
GST information
Product pricing
Settlement reports
Bank information
Seller credentials
Avoid unnecessarily sharing seller passwords or unrestricted marketplace credentials.
Where possible, use controlled exports, authorized integrations and appropriate access permissions.
The ideal objective is not to create a one-time Excel conversion.
It is to establish a repeatable process.
A scalable workflow may look like:
Amazon Reports
→ Automated Data Preparation
→ GST Validation
→ SKU Mapping
→ Sales Classification
→ Returns Processing
→ Fee Classification
→ TallyPrime Import
→ Settlement Reconciliation
→ Bank Matching
→ Exception Report
Once this process is established, growing transaction volumes become easier to manage.
If sales increase from 500 orders to 5,000 orders, the accounting workload does not necessarily need to increase proportionately.
A tool may import 10,000 transactions quickly.
That does not prove the accounting is correct.
The real questions are:
Do gross sales reconcile?
Are returns included?
Are GST amounts appropriate?
Are marketplace fees accounted for?
Does the clearing account reconcile?
Does the settlement match the bank?
Does inventory reflect the intended movement?
Are there duplicate vouchers?
Were any transactions rejected?
Accuracy should always come before import speed.
For Amazon sellers in Bawana Industrial Area and Narela Industrial Area, the best accounting workflow is one where every major amount can be traced.
Management should be able to move from:
Bank Receipt
back to:
Settlement
then to:
Fees and Adjustments
and ultimately to:
Orders and Sales Transactions.
That traceability makes troubleshooting easier and provides better visibility into marketplace performance.
The purpose of Amazon-to-TallyPrime integration is therefore not simply automation.
It is financial clarity.
Amazon selling in 2026 requires more sophisticated accounting than simply recording the amount deposited into the bank. Sellers in Bawana Industrial Area and Narela Industrial Area may need to manage high-volume B2B and B2C sales, GST information, returns, refunds, marketplace charges, inventory movements, settlement adjustments and bank receipts.
A structured Amazon sales and settlement import workflow can reduce repetitive manual entry while improving the consistency and traceability of accounting information.
The process should begin with clean marketplace data, correct SKU and ledger mapping, GST validation and a controlled test import. Returns, refunds and marketplace charges should be accounted for according to their nature rather than being hidden inside the net settlement amount. Finally, settlement information should be reconciled with the corresponding bank receipts.
The objective is not simply to import Amazon data faster. It is to create an accounting trail where sales, GST, inventory, expenses, settlements and bank transactions can be reviewed and reconciled with confidence.
For growing Amazon sellers, manufacturers, wholesalers and distributors, a properly designed Amazon-to-TallyPrime process can transform marketplace accounting from a month-end data-entry burden into a controlled and scalable financial workflow.
Continue Here >>
Continue Here >>
Continue Here >>
