IDRS, ICS, ACS and ENTITY: The Computer Systems Behind Every IRS Employee's Screen

Ask an IRS employee why they cannot just fix something, and the honest answer is often a system answer. The update has not posted. The account is not on their screen yet. Their profile does not allow that command. The action will go out in the weekly run.

Those answers make more sense when you know the systems. Here are the main ones a collection case runs through, as the IRM describes them.

The Master File and IDRS

The official record of your account is the Master File: the Individual Master File for individuals and the Business Master File for businesses. Employees do not usually work directly on the Master File. They work through the Integrated Data Retrieval System, IDRS.

IRM 2.9.1 (rev. 2024-08-05) describes IDRS processing in the campuses and area offices. Accounts are extracted from the Master File to the IDRS Taxpayer Information File, called the TIF, when they meet extraction criteria, and are kept there as long as they meet retention criteria. When a module no longer meets any criteria, IRM 2.9.1 says it is dropped from the file and a transaction is generated to tell the Master File it is no longer on the TIF.

That is why an employee sometimes has to request your account before they can work it. IRM 2.9.1 notes that a command code can generate a request that pulls a specific module from the Master File and creates a dummy module on the TIF.

Command codes

Employees act on IDRS through command codes. IRM 2.9.1.1.7 says the specific instructions for using IDRS terminals and command codes are in IRM 2.3 and 2.4, and IRM 2.9.1.1.5 notes that where older procedures call for manual forms, the forms may be replaced by command codes while the underlying procedures still apply.

One example shows how much power sits in a few keystrokes. IRM 2.4.28 (rev. 2025-02-05) describes command code STAUP, which can update certain IDRS collection statuses in real time or request a specific status and notice during the weekly update, and can interrupt, delay, accelerate or skip routine notice issuance. The same IRM says STAUP will only prevent an erroneous notice if it is input by the Friday before the notice is scheduled to generate.

That is the kind of detail that explains why an employee says a notice already went out and nothing can be done. The weekly cycle has a cutoff.

ICS: Field Collection's case system

Revenue Officers work in the Integrated Collection System. IRM 5.1.20.4.3 (rev. 2024-10-07) describes it as providing workload management, case assignment and tracking, inventory control, electronic processing and case analysis tools, with a mainframe tier at the Tennessee Computing Center and software on each employee's workstation.

ICS is also where the officer writes the case history and requests lien filings, which IRM 5.1.20.4 says are extracted to the Automated Lien System. I describe the history in The Revenue Officer's Case History.

ENTITY: the inventory view

Managers see Field Collection inventory through ENTITY. IRM 5.1.20.4.1 describes it as a current database of Field Collection, Field Offer in Compromise and Advisory inventories, fed by ICS, by the Delinquent Inventory Account List for queue cases and by the Automated Lien System.

ENTITY reports can be run at the officer, group, territory, area or national level, and its GM Case Assignment function is how group managers pull cases from the queue. When a manager decides what to assign next, ENTITY is the screen they are looking at.

ACS: the campus collection system

The Automated Collection System has its own database and its own history codes. IRM 5.19.5 (rev. 2025-03-03) describes ACS as a computerized inventory system established in April 1984 to maintain balance due accounts and return delinquency investigations, accessible from call sites and support sites around the country.

ACS history codes generate letters and levies overnight and upload transactions to IDRS. IRM 5.19.5.4.3 also describes a daily update alert that blocks certain actions, like sending letters or issuing levies, when daily activity has posted to the account, until the weekend update runs. Again, the system's timing drives what the employee can do today.

For how ACS organizes its work, see Inside the Automated Collection System.

Shorthand you may hear

Employees talk in system shorthand. IRM 2.9.1.1.7 explains one example: the term 53'd means a tax module carries an unreversed TC 530, which means currently not collectible. When an employee says your account is 53'd, they mean collection is suspended as not collectible, not that the debt is gone.

The same transaction shows up in routing. IRM 5.1.20.2.2 says the Inventory Delivery System can shelve cases predicted to be inactive or unproductive using TC 530 with closing code 39. Two very different situations, a hardship determination and a resource-based shelving, both appear as a TC 530 with different closing codes.

Revenue Officers also read Account Management Services history. IRM 5.1.10.2 tells officers to review IDRS, ICS and AMS during pre-contact analysis and to note actions already taken by previous officers or ACS. The systems are separate, but the officer is expected to read across all of them before calling you.

The routing layer

Above all of these sits the Inventory Delivery System. IRM 5.1.20.2 says IDS receives cases from balance due and delinquency analysis, ACS, the automated substitute for return program and the queue, requests updated data from the IDRS TIF and from Corporate Files On-Line, and routes cases to Field Collection, the queue, ACS or the Automated 6020(b) program.

IDS also passes predictive model scores to each function's case management system for final prioritization. The decision about where your case goes, and how it ranks, is made by systems talking to systems before any employee looks at it.

Access is restricted, and browsing is a crime

These systems are locked down. IRM 5.1.20.1.5 says access to each inventory management system is restricted and requires an approved access request. IRM 5.19.5.2 describes ACS access profiles based on an employee's position and location, with user IDs revoked after 90 days of non-use. IRM 25.27.1.1.5 notes that the third party contact database is maintained within IDRS and subject to IDRS access controls.

IRM 2.9.1.1.5 is direct about employee conduct. IDRS users may access only the accounts required for their official duties, and may not access their own or a spouse's account, the account of a friend, relative or co-worker, or any account in which they have a personal or financial interest. The IRS prohibits access to satisfy personal curiosity. The same subsection says unauthorized browsing is a criminal misdemeanor under the Taxpayer Browsing Protection Act, punishable on conviction by automatic termination and a fine of up to $1,000, up to a year in prison, or both.

So when an employee says they cannot look at your spouse's separate account while working yours, they are not being difficult. They are following a rule that carries criminal penalties.

What this means for you

Most IRS frustration is timing. Payments post on cycles. Status changes run weekly. Notices generate on schedules with cutoffs. The employee you reach may be on a system that does not show what another function just did.

Practical advice: write down the date of every payment and agreement, ask the employee what system and what status they see, and when something has to stop, like a notice or a levy, ask whether there is still time before the next cycle. Precise questions get precise answers. Vague ones get it is in the system.