Why conflicting data is the norm, not the exception
The Indian mid-market business stack is heterogeneous by design. Multi-company Tally per SPV or branch. A CRM (custom or vendor) holding customer and pipeline data. An inventory or ERP module tracking stock and orders. An Excel scheme calendar reconciled weekly. WhatsApp threads documenting site coordination. Each system captures its own version of the same underlying business event.
Conflicts appear the moment two systems record the same event differently. The CRM says an order was booked on the 3rd; Tally has the invoice dated the 5th. The scheme Excel shows a discount that never got posted against the invoice. The godown-stock in Tally does not match the WMS receipts file for last Tuesday. None of this is a bug - it is the natural consequence of independent systems each doing their own job. The question is whether the analytics layer surfaces the conflict or paints over it.
The five most common cross-system conflicts
Almost every mismatch in an Indian mid-market data stack falls into one of five patterns. Recognising the pattern is the first step in resolving it.
- Same entity, different name. Customer "Sharma Enterprises Pvt Ltd" in Tally, "Sharma Ent" in CRM, "Sharma Enterprise" in the scheme sheet. Same customer, three identities. Any join fails until the mapping layer resolves it.
- Same event, different date. CRM records the order booking date; Tally records the invoice posting date; dispatch records the actual dispatch date. Question "how much did we bill in June?" has three defensible answers depending on which date you pick.
- Same amount, different definition. Gross vs net vs after-scheme. Tally posts gross invoice value; the scheme Excel records the accrual that gets deducted at quarter-end; the CRM tracks negotiated price. All three are "the amount" but none match without joining.
- Same count, missing records. The CRM shows 47 quotations sent last month. Tally shows 38 invoices posted. The gap is real - 9 quotations did not convert - but only visible when the two are joined side by side.
- Same record, different truth. Godown stock in Tally shows 240 units; the WMS receipt file shows 232; the physical stock count is 236. Three sources, three numbers. Reconciliation is the job; hiding two of the three is not.
How AI analytics handles conflicts, step by step
A well-designed AI analytics platform runs a five-step loop when it detects conflicts across sources. The loop is boring by design - boring is what makes it trustworthy.
- Step 1 - resolve identity. The mapping layer links the same entity across systems using a combination of exact match, fuzzy match, and business keys (GSTIN, PAN, phone number, PO number, invoice number). Ambiguous matches are flagged for review during the 14-day POC, not auto-resolved silently.
- Step 2 - normalise the definition. The metric definition is fixed once during the POC and enforced thereafter. "Revenue" means one thing across every question; the platform explicitly notes when a user's phrasing implies a different definition (gross vs net, before or after scheme).
- Step 3 - join at query time. When the question needs data from two or more sources, the platform reads each live, joins them at query time using the resolved identities, and computes the answer against the normalised definition. No warehouse copy in between.
- Step 4 - flag the specific difference. If the joined view shows a conflict, the platform surfaces the exact difference: this invoice number is in CRM but not Tally, this amount differs by ₹18,432 with the ledger figure being lower, this date is 3 days apart. Not a vague "discrepancy" label - the specific field and the specific delta.
- Step 5 - show which source supports each answer. For every number in the answer, the platform names the source system, the exact records included, and the timestamp of the read. The user knows whether the number came from Tally, CRM, or both - and can drill down to verify at the record level.
What the user actually sees in a conflict view
The user experience matters as much as the underlying loop. Three concrete outputs a good AI analytics platform produces when asked about data with conflicts.
| Question asked | Naive response | Conflict-aware response |
|---|---|---|
| "How much did we bill customer Sharma last month?" | One number - which one is a guess. | Tally invoice total: ₹4.82L. CRM order value: ₹5.11L. Difference: 1 unposted invoice worth ₹29K. Drill-down to both. |
| "What is our stock of SKU 7714 in the Pune godown?" | One number - Tally stock ledger. | Tally: 240 units. WMS receipts: 232 units. Physical count last audit: 236 units. Variance flagged for reconciliation. |
| "What is my top customer's margin this quarter?" | Gross margin from Tally. | Gross margin: 24.3%. After scheme accrual (Excel): 19.1%. After payment-term interest cost: 17.8%. All three shown with source. |
| "Did we ship all June orders?" | "Yes" based on the last dispatch report. | CRM orders: 47. Dispatched (per dispatch app): 43. Invoiced (Tally): 44. Gap identified: 4 orders unshipped, 1 shipped-not-billed. Drill list. |
How KolossusAI handles this in practice
KolossusAI's AI Analytics Platform reads Tally, custom and vendor CRMs, ERPs, Excel and Google Sheets, and REST / GraphQL APIs in place via native connectors - no warehouse in between. The business-vocabulary layer is configured during the 14-day POC: entity mapping across systems, metric definitions signed off between owner and finance head, date convention chosen per question type. Every answer shows the source system per number, links to the underlying voucher or record, and is logged for audit.
- Source-system reads, no warehouse copy. Data stays where it lives. Freshness is voucher-latest, not warehouse-refresh-latest. Reconciliation is between live source systems rather than between yesterday's ETL snapshots.
- Mapping layer with fuzzy match plus business keys. Customer entity resolution uses GSTIN / PAN / phone as strong keys, name similarity as a weak key. Ambiguous matches surface for human review during POC; the mapping is versioned so changes are traceable.
- Explicit metric definitions. One definition per metric, chosen and documented during setup. When a question implies a different definition, the platform names the alternative rather than silently switching.
- Query and source shown for every answer. The user sees the query that ran, the source rows included, and the join logic. Nothing about the answer is a black box that only the vendor can inspect.
- Read-only default; write-back is a separate opt-in. The analytics layer does not silently fix conflicts in your source data. If a conflict resolution needs a voucher edit or a status update, that is a distinct workflow with human approval gated on it.
What AI analytics honestly cannot fix on its own
The category has real limits. Any vendor claiming AI resolves all conflicts automatically is hiding either the fix or the errors.
- AI cannot invent the correct answer when the data is genuinely wrong. If Tally has the invoice amount wrong because the accountant keyed it wrong, no analytics layer can deduce the true amount from other systems. It can flag the mismatch; the human still fixes the voucher.
- AI cannot decide which source is authoritative for a business. "When Tally and the CRM differ, which one is right?" is a policy question, not a technical one. The owner decides the source-of-truth rule (usually Tally for financials, CRM for pipeline); the AI enforces the rule.
- AI cannot normalise data that was never captured. If a scheme was applied verbally over WhatsApp and never entered anywhere, no AI reads it. The gap surfaces (Tally invoice higher than CRM negotiated price) but the fix requires the human to log the scheme somewhere.
- AI cannot resolve identity conflicts without initial mapping. The mapping layer is set up once during the POC and maintained as the business grows. Fully unsupervised entity resolution across noisy Indian mid-market data is not reliable enough for decision-grade work today.
The honest framing: AI analytics turns invisible conflicts into visible ones with the specific delta and drill-down. That is a genuine step change from the manual Excel reconciliation cycle. But conflict resolution remains a human-approved action, not a fully automated fix.
The verdict and how to test it in two weeks
A serious AI analytics platform handles conflicting data by joining sources at query time, flagging the specific difference (not a vague discrepancy label), and showing which source supports each answer with drill-down to the record level. What it does not do is invent the correct number when the underlying data is wrong, or decide the source-of-truth rule for your business.
See how KolossusAI works for the architecture in detail. The 14-day POC is free, founder- led, and runs on your real systems. Day 4 to 7 is dedicated to conflict testing - the validation owner asks the same question across systems and confirms that mismatches surface honestly rather than get papered over. That honesty is the offer.