enReconcile by Taxilla can be used to set up any reconciliation between any two data sources. These data sources for reconciliation can be from the same organization or between an Org and sub-organization or between two organizations.
The following list has some of the use-cases that are used by our customers. The list is not exhaustive and does not include private use-cases published for private subscription.
- Bank Statement Reconciliation
- Purchase Register Vs GRN
- Reconciliation of GSTR-2B With Purchase Register
- 26AS Vs Books of Accounts
- E-commerce reconciliations
- Insurer Policy vs. Brokerage Order Booking (Not provided as case study)
- Reconciliation of Suspense Accounts by a major Insurer
1. Bank Statement Reconciliation
1.1 Objective
- To reconcile each entry in the financial record of client's core system with the entity's bank account statement.
- To confirm that payments have been processed and cash/DD/cheque collections have been deposited into a bank account.
- To Calculate and identify outstanding and excess payments
- To compare the cash balance on client's balance sheet with the corresponding amount on its bank statement.
1.2 Process Flow
1.3 Recon criteria
- Date of Transaction.
- Deposit amounts, deposits in transit, outstanding checks, add/deduct bank charges,
1.4 Additional Recon Configurations
- Tolerances
- Fuzzy Logic
1.5 Recon Steps
- Identifying the recon criteria in Bank Statement & Purchase Register.
- If all the 3 criteria are matching, then will be considered as ‘Exact Match’.
- Only if transaction amount & Party name are matching, will be considered as ‘Probable Match’.
- ‘Force Match’ will allow user to reconcile/map the transaction manually.
- Transactions which were not falling under any of the above categories will be considered as ‘Not Matched’.
1.6 Advantages
- To Identify the unrecorded lodgments.
- Helps to Identify the Duplicate Entries.
- To Validate data entry/Identifying accounting errors/discrepancies w.r.t AP ledger.
2. Purchase Register Vs GRN
2.1 Objective
- To Identify the difference in quantity between Tax Invoice & GRN
- To Identify the product (HSN) mismatch.
- To have a check on purchase requisition between GRN & PO quantity.
2.2 Process Flow
2.3 Recon criteria
- Invoice Number & PO Number.
- Supplier GSTIN.
- Period.
- Product description (HSN) & Quantity.
- Taxable Value, Invoice Value.
2.4 Additional Recon Configurations
- Tolerances
- Fuzzy Logic
- 3 Way Match with eInvoice or Delivery Note/BoL
2.5 Recon Steps
- Identifying the recon criteria in Purchase Register & GRN.
- If all the criteria are matching, then will be considered as ‘Exact Match’.
- Only if Invoice Number, Supplier GSTIN & Product description are matching, will be considered as ‘Probable Match’.
- ‘Force Match’ will allow user to reconcile/map the transaction manually.
- Transactions which were not falling under any of the above categories will be considered as ‘Not Matched’.
2.6 Advantages
- Reducing the risk of the double booking of purchases.
- Ensuring accuracy of Good Receipts.
- Identifying non-receipt of invoices or goods from Vendors.
- Ensuring invoices are being matched to Goods received.
- Share and collaborate with vendors to resolve discrepancies.
3. Reconciliation of GSTR-2B With Purchase Register
3.1 Objective
Reconciliation of GSTR-2B available in GST Portal with Purchase register to identify the any difference or variance in the ITC.
3.2 ITC - Reconciliation Process
User has to Get/Upload the input data (GSTR-2B & Purchase Register) for reconciliation, once data is received recon will start based on matching criteria.
3.3 Recon criteria
- Financial Year,
- Supplier GSTIN
- Invoice Number
- Section
- Tax Amounts- For tax amounts both positive and negative tolerance need to be applied.
Exact Match
- Reconciliation would be done on unreconciled Invoices from Inward and GSTR-2B.
- Partitioning would be on Supplier GSTIN, Financial Year and Transaction Category (B2B, B2BA, CDN, CDNA, ISD, ISDA).
- Regular and amendment invoices will also be reconciled separately
- Reconciliation would be done Financial Year-wise, and matching will be done on Supplier GSTIN, Invoice Number, Financial Year, Section, Tax Amounts
Probable Match
- Probable Match is done on unmatched invoices from Reconciliation with Exact Match
- Currently, Probable match does not support auto-tolerance of tax amounts due to technical limitations in matching.
- Probable match consists of stage-wise matching to identify the best probable matches among the unmatched
invoices
- Pattern based matching on Financial Year, Supplier GSTIN, Transaction Category, Invoice Number Pattern, Invoice Date and Tax amounts (IGST + CGST + SGCST rounded off to the nearest rupee).
- Invoice Date and Tax amounts based probable match on Financial Year, Supplier GSTIN, Transaction Category, Invoice Date and Tax amounts (IGST + CGST + SGCST rounded off to the nearest rupee).
- Tax amounts based probable match on Financial Year, Supplier GSTIN, Transaction Category and Tax amounts (IGST + CGST + SGCST rounded off to the nearest rupee).
Vendor PAN Match
- After probable match system will match the unmatched invoices with vendor PAN which means Vendor GSTIN in 2A & Inward belongs to same vendor but booked with different GSTIN numbers
- For invoices to be matched, the Supplier GSTIN, Invoice Number has to be matched along with tax amounts. For tax amount comparison, both positive and negative auto-tolerance need to be applied. The auto-tolerance values are configured via setup attributes
Forced Match and Unmatch Options
Forced Match is to use manually match an invoice from Inward with an invoice from GSTR-2A even if the GSTR-2A reconciliation has not matched them using either exact match or Probable match on pattern/dates/tax amounts etc.
Unmatch option used to remove Probable match suggested by GSTR-2A reconciliation.
3.4 Reconciliation Logic
Exact Match
Reconciliation would be done Financial Year-wise, and matching will be done on Supplier GSTIN, Invoice Number, Financial Year, Section, Tax Amounts
Probable Match
- Pattern based match-If Financial Year, supplier GSTIN, invoice date, tax amounts, invoice type are matched exactly and invoice Number’s are matched based on pattern logic
- Probable match based on Invoice date and Tax Amounts- If Financial Year, supplier GSTIN, invoice type, invoice date, tax amounts matched exactly. (Invoice Number’s is not considered in this stage for reconciliation).
- Probable match based on Tax Amounts- If Financial Year, supplier GSTIN, invoice type, tax amounts matched exactly. (Invoice Number’s and invoice date are not considered in this stage for reconciliation).
- Vendor PAN Match-If Supplier PAN, Financial Year, Invoice Number, tax amounts, Section matched exactly.
3.5 Additional Recon Configurations
- Tolerances
- Fuzzy Logic
- 3 Way Match with eInvoice
3.6 Recon Steps
- Get/Upload the input data (GSTR-2B & Purchase Register)
- Provide positive/Negative tolerance
- Initiate recon
- Exact Match Recon based on matching criteria (User can Download exact match report)
- Probable Match Recon based on matching criteria (User can download Probable match report)
- Vendor PAN Match Recon
- Force Match
- Consolidated Report with all matching tags
3.7 Major Features
- Multi-month and multi-year reconciliation
- Reconciliation option at Transaction level
- Mismatched/un-matched invoices Carry forward
- Manual Match/Force Match
- Detailed and summary reports are available with Automatic tagging of invoices
- Pan-India Reconciliation Reports
- Email the reconciliation reports
- Reconciliation dashboards for purchase insights and ITC trends
3.8 Advantages
- Identify the suppliers who are default in file their GST returns
- Reconciliation will help to claim correct ITC in GSTR-3B
- It will help to identify the working capital requirement
- This eliminates ITC Mismatch notices from GST Department
4. 26AS Vs Books of Accounts
4.1 Objective
Reconciliation of form 26 AS issued by the Income Tax Department and books of accounts to identify which Tax deductors had not deposited the amount
4.2 TDS Reconciliation Process
We have two inputs here one is 26 AS and another one is books of account data for reconciliation, user has to upload the inputs files then recon will start based on matching criteria (TAN from 26As, TAN from books, TDS deposited from 26As, TDS receivable from books).
4.3 Recon Steps
- Upload the input data (26AS and Books of account data)
- provide Positive/Negative tolerance
- Initiate Recon
- Out-put Report with different match tags (Exact-Match, Matched with tolerance, Unmatched)
4.4 Reconciliation Logic
Exact Match
- Reconciliation would be done based on data from 26As and books of accounts.
- If TAN from 26AS & books of accounts, TDS deposited from 26As & books of accounts are matched exactly then termed as a “Exact Match”
Matched with Tolerance
- Reconciliation will be done based on unmatched invoices from Reconciliation with exact match
- If data is matched with tolerance, then termed as a “Matched with Tolerance”
4.5 Additional Recon Configurations
- Tolerances
- Fuzzy Logic
4.6 Advantages
- Identify the tax deductors who didn’t remit TDS to the government
- Better control over TDS Receivable’s
- save working capital, ensure accurate TDS credit claims, and create a strong audit defense.
- Proactive tracking of discussions with tax deductor/collector for corrections due to identified mismatches
5. Ecommerce Merchants vs Marketplace and Logistics
5.1 Objective
Reconciliation of the data received from market places and logistics providers with the internal data of ecommerce merchants
5.2 Reconciliation Process
5.3 Recon Steps
- Input data is pulled from the source system where API is available. Files are uploaded manually otherwise.
- provide Positive/Negative tolerance
- Initiate Recon
- Output Report with different match tags (Exact-Match, Matched with tolerance, Unmatched)
5.5 Additional Recon Configurations
- Tolerances
- Fuzzy Logic
5.6 Advantages
- Identify the orders with mismatches and alert the concerned parties
- Better control over exception management.
- Tracking and collaborative resolution with marketplace / logistics partner on identified mismatches
- Zero loss due to missing payments, returns not received, etc.
Nota Bene:
This document is for informational purposes only and may not be incorporated into a contract or agreement.
The information presented in this document is subject to change without prior notice and should not be
construed as a commitment by Taxilla IT Solutions Private Limited or Taxilla Inc. The information in this
document is confidential and may be legally privileged. It is intended solely for the purpose of evaluation
and distribution with anyone else for purposes other than this is unauthorized.
All information in this presentation is current at 2021-21-12, unless otherwise stated.