Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can build a JavaScript tool that compares normalized tax-return figures with AIS/TIS information and explains what needs review. It cannot reproduce the Income Tax Department’s scrutiny-selection system or predict whether a return will be selected. Treat each result as a reconciliation prompt, not a finding of noncompliance.
What are AIS and TIS, and how do their values differ?
The Income Tax Department describes the Annual Information Statement (AIS) as a view of information currently available to it for a taxpayer. It can include TDS/TCS, specified financial transactions and other reported information. AIS is not a complete inventory of a taxpayer’s activity: the Department cautions that other transactions may not appear, and taxpayers remain responsible for reporting complete and accurate information in their returns.
The Taxpayer Information Summary (TIS) presents information as category-wise aggregates. For a category, distinguish at least two kinds of values:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- System-processed value: the value after the Department’s processing, including deduplication under predefined rules.
- Accepted or confirmed value: the value accepted by the taxpayer or confirmed by a source after feedback. The Department says accepted or confirmed TIS information is used for prefilling where applicable.
A comparison tool should preserve these as separate values rather than flattening them into one “AIS amount.” AIS also provides feedback on active information and shows reported and modified values, so feedback status and provenance can change how a record should be reviewed.
#1 Best Overall
How does Form 26AS fit?
Form 26AS is narrower in scope: the Department describes it as displaying TDS/TCS-related data, while other taxpayer information is available in AIS. AIS supports feedback, and information-source-level aggregation is reflected in TIS. A tool that treats Form 26AS and AIS as interchangeable may miss information or compare unlike datasets.
Does an AIS mismatch automatically mean scrutiny?
No. A difference between a return figure and an AIS or TIS value is a reason to investigate the underlying records; by itself, it does not establish that tax is owed or that scrutiny will follow.
A Government of India parliamentary answer describes enhanced financial data streams being analysed for disclosure gaps, mismatches, high-risk patterns and potential evasion. It says cases are selected through a rule-based automated system informed by analysis of financial data from multiple sources, including third-party information. The public description does not disclose the actual selection rules, thresholds, weights, scoring formula, code or decisions for individual taxpayers.
Rank #2
The Department’s assessment page describes FY 2024-25 compulsory scrutiny-selection guidance. Under that year’s guidance, returns filed in response to certain notices based on NMS/AIS/SFT/CPC-TDS/IC&I information were not compulsory scrutiny solely for that reason; selection was through CASS. This is specific to FY 2024-25, not a statement of criteria for another year. Check the applicable year’s current circular before relying on year-specific selection guidance.
How should an AIS/TIS comparison work?
Start with records and their context, not a score. The Department lists PDF, JSON and CSV downloads for AIS, which can support a prototype import flow. The cited official material does not establish a public external API or a stable field-level schema for third-party JavaScript applications. Treat file parsers and assumptions as versioned; verify them against current official files and utility documentation. The normalized fields below are an internal example, not official AIS field names.
Keep provenance and value states separate
For each imported item, retain enough information to explain what was compared and why. A practical internal record might look like this:
const record = {
source: "AIS", // Internal label, not an official field
taxYear: "2024-25",
period: "annual",
sourceDescription: "Example reported item",
category: "interest",
reportedAmount: 12500,
processedAmount: 12500,
acceptedAmount: null,
feedbackStatus: "not-recorded",
modifiedAmount: null,
sourceRecordId: "example-001"
};Use null when a value is unavailable; do not silently substitute zero. Keep the taxpayer’s return figures in a separate structure, with their own period and category mapping. Preserve original input data alongside normalized values so a reviewer can trace a finding back to its source.
Recommended Free Tools
Normalize inputs without assuming a government schema
Build an import adapter for each file format or supported version, then map parsed data into your own documented model. Validate amounts, periods, categories and identifiers; capture parse failures rather than dropping records. A changed source file or utility may require an adapter update. Do not describe a prototype parser as officially supported or stable unless current Department documentation establishes that compatibility.
Compare only records that can reasonably be matched
Before comparing amounts, check whether the period and category align and whether the source record plausibly corresponds to the return figure. A reported amount, a system-processed aggregate and a taxpayer-accepted value may differ for reasons that cannot be inferred from amount alone. Records with uncertain period or source mapping should go to human review instead of being forced into a match.
Rank #4
Can you build the rules in JavaScript?
Yes, as a transparent review aid. The following example operates only on already-normalized records. It flags a return amount that differs from a selected record amount; it does not parse an official file, apply tax law, determine liability or model the Department’s selection system. The threshold is an arbitrary demo setting, not a legal or government threshold.
const RULE_VERSION = "demo-1";
const DEMO_TOLERANCE = 1;
function compareAmounts({ returnItem, sourceItem, amountField = "reportedAmount" }) {
const sourceAmount = sourceItem[amountField];
if (typeof returnItem.amount !== "number" ||
typeof sourceAmount !== "number") {
return {
ruleId: "DEMO-AMOUNT-COMPARISON",
ruleVersion: RULE_VERSION,
status: "review",
reason: "One or both amounts are unavailable or not numeric.",
returnItemId: returnItem.id,
sourceRecordId: sourceItem.sourceRecordId
};
}
const difference = returnItem.amount - sourceAmount;
if (Math.abs(difference) <= DEMO_TOLERANCE) return null;
return {
ruleId: "DEMO-AMOUNT-COMPARISON",
ruleVersion: RULE_VERSION,
status: "review",
reason: `Return amount differs from ${amountField} in the normalized source record.`,
returnItemId: returnItem.id,
sourceRecordId: sourceItem.sourceRecordId,
returnAmount: returnItem.amount,
sourceAmount,
difference
};
}Choose the comparison field explicitly. A workflow might compare the reported amount first, then let a reviewer inspect processed, accepted or confirmed, and modified values with their feedback status. Do not silently substitute one value state for another.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Make rules deterministic and explainable
Give every check a stable identifier and version, declare its inputs, and return the records and reason that triggered it. Useful illustrative checks include:
- A return amount differs from a mapped source record.
- Two records appear duplicate-like and need inspection rather than automatic deletion.
- A record’s period, category or source mapping is uncertain.
- A feedback or modification value exists and should be reviewed alongside the reported value.
These are demo rule categories, not published CBDT criteria. Do not combine them into an opaque “risk score.” If a demonstration includes a score, disclose that its weights are arbitrary prototype choices and do not describe it as a government score or scrutiny probability.
Return findings that can be audited
Store the rule identifier and version, input record identifiers, compared value states, result, reason and any unresolved mapping issue. This lets a reviewer reconstruct what the engine saw without treating its output as a tax conclusion. Keep a path for a person to resolve conflicts, missing records and uncertain treatment, and record the reviewer’s decision separately from the rule result.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should developers test and review?
Testing should target the parser and each deterministic rule, using representative files obtained from current official downloads and documentation. Since no stable external schema is established here, a prototype should not assume that field names, formats or availability will remain unchanged.
Quick Recap
- Reject or isolate malformed amounts, missing periods and unknown categories rather than silently coercing them.
- Check that reported, processed, accepted or confirmed, and modified amounts remain distinct through import and comparison.
- Verify that a missing value is not interpreted as zero and that uncertain matches are routed for review.
- Include rule identifiers and versions in every finding so a later rule change does not obscure how an earlier result was produced.
- Require a human to reconcile a difference against supporting records before drawing a tax conclusion.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
