IRIS validates a submission in two stages, and the business-rule catalog is the second and harder one. Once your XML clears the schema check, the IRS runs it against a published set of business rules — identified by prefixes such as TMFST, S1H, and SHAREDIRFORM — that compare your data against the IRS database, against itself, and against the rest of the transmission. Each rule carries a severity: a Reject stops the affected record or transmission cold, while a Report Error is logged as an advisory unless it crosses a threshold. Knowing which rule fired, and whether it rejects or merely warns, is the difference between a one-line fix and a guessing game.
In this story
Why a Valid File Still Gets Rejected
Most filers assume that if their XML opens in a validator without complaint, the hard part is over. It isn't. The schema check only confirms that your file has the right shape — the right elements, in the right order, holding the right data types. The business rules are an entirely separate gate that asks a different question: does this data actually make sense, and does it agree with what the IRS already knows?
Think of it as two walls in series. The first wall is the schema, defined by the XSD files the IRS publishes as part of the IRIS Application-to-Application package described in Publication 5717. It rejects a file that is malformed — a missing required element, a TIN that isn't nine digits, an amount with letters in it. The second wall is the business-rule catalog, and it only comes into play after the schema wall has let your file through. This is where a structurally perfect document gets turned away because its tax year doesn't match the manifest, or because the name attached to a TIN doesn't match the IRS database, or because a Combined Federal/State election was placed in the wrong submission group.
The practical consequence is that you cannot debug an IRIS rejection by re-validating against the schema. If the IRS quotes you a rule number, the schema already passed — the problem lives in your data or in how the pieces of your transmission relate to one another. That is why this catalog matters: the rule ID in your acknowledgement is a precise address, and once you can read the address, the fix is usually obvious.
The two-layer validation model and the A2A business-rule package are defined in IRS Publication 5717, the IRIS Application-to-Application specification. The companion Publication 5718 and Publication 5719 cover the portal and the assurance-testing process where you first encounter these rules.
How to Read a Rule ID Before You Read the Message
Every IRIS business rule has a short identifier, and the prefix on that identifier tells you which part of your transmission the rule is checking. This is genuinely useful triage: before you read a word of the rule text, the prefix already tells you whether to look at your transmission envelope, your submission header, an individual form record, or the relationship between submissions. The catalog organizes itself around the document hierarchy — transmission contains submissions, submissions contain form records — and the prefixes mirror that nesting.
| Prefix | Layer it checks | Representative rule |
|---|---|---|
TMFST / FTMFST | Transmission — the manifest, TCC, software ID, and counts | TMFST002: the TransmitterControlCd must match the TCC on file |
SMF | Submission manifest — tax year, issuer name/TIN, form authorization | SMF007: submission TaxYr must match the manifest TaxYr |
S1H / S2H / S3H | Submission header — one per submission type (1099 series, extensions, 1042-S) | S1H022: a 1099-R submission must carry Form1099RTotalAmtGrp |
SMD | Submission detail — the form-type to detail-group pairing | SMD001: a declared form type must carry its matching Detail group |
SHAREDIRFORM | Every form record — recipient TIN/name, corrections, CF/SF | SHAREDIRFORM020: a state election requires the header CF/SF flag |
The SHAREDIRFORM family deserves special attention because it applies to every form record regardless of type, which makes it the busiest source of real-world rejections. A rule such as SHAREDIRFORM014 checks that a recipient's person name and TIN together match the IRS database, while SHAREDIRFORM023 simply insists that a recipient TIN is present at all. Because these rules touch every record, a small data-quality problem in your source system multiplies across the whole file.
You will also see suffixes like _001 or _002 on some IDs — for example TMFST002_001 or SHAREDIRFORM019_002. Those are revision markers the IRS uses when it tightens or restates a rule across schema versions. The base number is what matters for diagnosis; the suffix tells you which wording is current for the tax year you are filing, which for this content is the TY2025 v1.4 package.
Reject vs Report Error: The Severity That Decides Your Day
Two rules can describe nearly identical problems and have completely different consequences, because IRIS assigns each rule a severity. Reading the rule text without the severity is like reading a road sign without knowing whether it's a warning or a wall.
A Reject is the wall. When a Reject-severity rule fires, the affected unit does not get filed — depending on where the rule lives, that can mean a single record, a whole submission, or the entire transmission is turned away and must be corrected and resent. Most of the structural and identity rules are Rejects: SMF007 rejects a submission whose tax year disagrees with the manifest, and S1H022 rejects a 1099-R submission that is missing its required total-amount group. These are non-negotiable; there is no partial credit.
A Report Error is the warning. The IRS logs the issue and returns it in your acknowledgement, but the record is still accepted. Many of the contact-detail and advisory rules behave this way — S1H001, which wants a phone number in the issuer detail, is a Report Error rather than a Reject. The catch is that a Report Error is not always free: some rules carry the severity Report Error and Reject if Over Threshold, meaning the IRS tolerates a few violations but flips them to a hard reject once too many records in the submission trip the same rule.
A standalone rule, ThresholdRule, states that the allowable percentage of errors for any single business rule on any form in a submission must not exceed a configurable threshold the IRS sets. In practice this means a Report Error you've been ignoring all season can suddenly reject an entire submission once the bad records pile up — for example a high rate of SHAREDIRFORM016 missing-address violations, which is explicitly a “Report Error and Reject if Over Threshold” rule. Treat advisories as latent rejects, not as noise.
| Severity | What happens | Example rule |
|---|---|---|
Reject | The record, submission, or transmission is refused; fix and resend | SMF007 — tax-year mismatch |
Report Error | Logged in the acknowledgement; the record is still accepted | S1H001 — missing issuer phone number |
Report Error and Reject if Over Threshold | Tolerated up to a limit, then becomes a hard reject | SHAREDIRFORM016 — missing recipient address |
The Rules That Check You Against the IRS Database
A large and unforgiving slice of the catalog does something your own validator never can: it compares your data against records only the IRS holds. These are the identity rules, and they are the reason a file that looks flawless on your machine can still come back rejected. At the transmission level, TMFST002 confirms that the Transmitter Control Code in your manifest actually belongs to you, and TMFST018 and TMFST019 confirm that the software ID you sent is registered and, for production transmissions, marked Production rather than Test.
At the issuer and recipient level, the rules reach into the IRS name-and-TIN database directly. SMF017 and SMF018 require that the issuer's person name or business name match the TIN on file, and at the form-record level SHAREDIRFORM014 and SHAREDIRFORM015 do the same for each recipient. This is effectively the same matching the IRS TIN Matching service performs, applied to your live filing. Because these rules depend on data you cannot see, the only defense is to run TIN matching before you transmit rather than discovering the mismatch in your acknowledgement.
Of the 234 active rules in the TY2025 v1.4 package, a subset — the TCC, software-ID, and name/TIN-database checks — simply cannot be evaluated from the payload alone, because the authoritative answer lives in the IRS database. A responsible pre-validator can encode the structural and relational rules in full but can only flag the database rules as advisories, since a stale local copy of a code list should never produce a false rejection. The IRS remains the authority on those.
Combined Federal/State Filing: The Rules That Catch Everyone
If there is one corner of the catalog that rejects clean-looking filings more than any other, it is Combined Federal/State Filing. The CF/SF rules are subtle because they are relational — a single state election has to agree with a header flag, with a state-totals group, and, less obviously, with its position in the transmission.
The CF/SF program lets the IRS forward your federal 1099 data to participating states so you don't file twice. To opt in, you set a header flag and tag the relevant records, and three rules police that you did it consistently. SHAREDIRFORM020 says that if any record carries a CFSFElectionStateCd, then the submission header's CFSFElectionInd must equal 1. SHAREDIRFORM022 adds that the same election requires at least one TotalByStateGrp to be present. And SHAREDIRFORM019 restricts the state code itself to the list of states that actually participate in the program. Miss any one of these and the IRS reports the election as broken.
There is a deeper trap that the rule text alone won't warn you about. In a multi-submission transmission, the IRS only honors a CF/SF election when it sits in the first submission group. Place an otherwise-perfect CF/SF election in a later group and the IRS reads the header flag as 0 — firing SHAREDIRFORM020 and SHAREDIRFORM022 against the first group, even though the later submission was locally well-formed. The transmitted bytes were correct; the system keys the rule off submission position. The fix is to order any CF/SF-electing submission first in the transmission.
<!-- Illustrative: a CF/SF election must agree across three places -->
<IRSubmission1Header>
<CFSFElectionInd>1</CFSFElectionInd> <!-- SHAREDIRFORM020: must be 1 -->
...
</IRSubmission1Header>
<RecipientDetail>
<CFSFElectionStateCd>CA</CFSFElectionStateCd> <!-- SHAREDIRFORM019: participating state -->
</RecipientDetail>
<TotalByStateGrp>...</TotalByStateGrp> <!-- SHAREDIRFORM022: at least one required -->Two submission-header rules back up the form-level checks: S1H002 requires that if the header CF/SF flag is set, the transmitting TCC must actually be enrolled in the CF/SF program, and S1H003 restricts CF/SF to the specific form types the program supports, such as 1099-INT, 1099-DIV, 1099-MISC, 1099-NEC, and 5498. Both are Report Error severity, but a dropped state forwarding is exactly the kind of advisory you don't want to learn about after the deadline.
Counts, Corrections, and the Rules That Check Your Math
A third group of rules never touches the IRS database at all; they only check your transmission against itself. These are the consistency rules, and they are the easiest to prevent because everything they need is in your own file. The counting rules are the classic example: TMFST026 requires that the issuer count in the manifest equals the actual number of issuers, FTMFST009 requires that the manifest's recipient-form count equals the real total, and FS1H003 requires that each submission header's reported form count matches the forms inside it. An off-by-one here is almost always a generator bug, not a data problem.
The correction rules are where consistency gets strict, because a correction has to be internally coherent about what it is replacing. SHAREDIRFORM006 requires a UniqueRecordId on any record marked corrected, while SHAREDIRFORM007 requires that an uncorrected record carry no such ID and no previously-submitted group — the two are mirror images, and violating either signals that your correction flags and your linkage data disagree. Replacement transmissions add their own pairing rules, such as S1H050, which requires a replacement to keep the same form type as the original submission it replaces.
Common Rejection Reasons (and How to Avoid Them)
These are the business-rule failures that account for the bulk of avoidable rejections. Each one is a real rule from the TY2025 catalog, and each has a concrete, repeatable fix — the goal is to catch them before you transmit rather than after the acknowledgement comes back.
Cause: a record carries a CFSFElectionStateCd but the submission header's CFSFElectionInd is not set to 1, or the election sits in a submission that isn't first in the transmission — firing SHAREDIRFORM020 and SHAREDIRFORM022. Fix: set the header flag whenever any record elects a state, include at least one TotalByStateGrp, and order the CF/SF-electing submission first.
Cause: the TaxYr in a submission or form record doesn't match the value in the transmission manifest, tripping SMF007 or SHAREDIRFORM002. Fix: derive the tax year once at the top of your generator and stamp the same value into the manifest, every submission header, and every record — never let two code paths compute it independently.
Cause: a recipient or issuer name doesn't match the TIN on file, firing SHAREDIRFORM014 or SHAREDIRFORM015 at the record level, or SMF017/SMF018 at the issuer level — and at volume these can cross the threshold into a hard reject. Fix: run IRS TIN matching on your recipient and issuer data before you build the file, because this is the one rule class your own validator cannot confirm.
Cause: the form or issuer count in the manifest or a submission header doesn't equal what's actually inside, tripping TMFST026, FTMFST009, or FS1H003. Fix: compute every count from the assembled object graph at serialization time rather than carrying a count from an earlier step that a later edit could invalidate.
Cause: the form type is declared but its required structure is absent — for example a 1099-R without Form1099RTotalAmtGrp (S1H022) or a form type missing its matching Detail group (SMD001). Fix: drive generation from the form type so the correct total-amount group and detail group are always emitted together, never one without the other.
The Only Reliable Strategy: Check Every Rule Before You Send
The pattern across every rejection above is the same: each one was knowable before transmission. The structural and consistency rules can be checked in full from your own payload, and the database rules can at least be flagged in advance through TIN matching. A pre-submission pass that runs the entire catalog against your file turns a rejected transmission and a reset clock into a list of fixes you handle quietly at your desk. The alternative — transmit, wait for the asynchronous acknowledgement, decode the rule IDs, fix, and resend — burns days you usually don't have near a deadline.
Tired of decoding rule IDs after the fact?
e1099f runs built-in rule validation across all 234 checks before anything is transmitted, so you fix problems on your screen instead of in an IRS acknowledgement.
Skip Memorizing the Catalog Entirely
All 234 rules, pre-checked
Every client-validatable rule in the TY2025 catalog runs against your data before submission.
TIN matching built in
The name-and-TIN database rules are surfaced as warnings before you transmit, not after.
CF/SF placed correctly
The election lands in the first submission with its header flag and state totals set automatically.
A Receipt ID, not a rule code — the first time, for every form type.
Frequently Asked Questions
What is the difference between a schema error and a business-rule error?
SMF007) or a name that doesn't match the TIN (SHAREDIRFORM014). If the IRS quotes you a rule ID, the schema already passed.How many IRIS business rules are there?
What does the prefix on a rule ID tell me?
TMFST and FTMFST are transmission-level; SMF, S1H, S2H, S3H, and SMD are submission-level; and SHAREDIRFORM applies to every form record regardless of type. The prefix lets you locate the problem before you read the rule text.What's the difference between a Reject and a Report Error?
Can a Report Error still cause a rejection?
SHAREDIRFORM016 for missing recipient addresses. The standalone ThresholdRule states that the allowable error percentage for any single rule on a form is configurable, so a tolerated advisory can flip to a reject at volume.Why does my CF/SF election keep getting rejected when the data looks correct?
CFSFElectionStateCd) requires the header flag CFSFElectionInd to equal 1 (SHAREDIRFORM020) and at least one TotalByStateGrp (SHAREDIRFORM022). In a multi-submission transmission, the election must also sit in the first submission group, or the IRS reads the flag as 0.Which forms are eligible for Combined Federal/State Filing?
S1H003 restricts CF/SF to specific form types, including 1099-B, 1099-DIV, 1099-G, 1099-INT, 1099-K, 1099-MISC, 1099-NEC, 1099-OID, 1099-PATR, 1099-R, and 5498. Rule SHAREDIRFORM019 separately limits the state code to states that participate in the program.Why can't my own software check every rule?
What does a suffix like _001 or _002 on a rule ID mean?
TMFST002_001 or SHAREDIRFORM019_002. The base number identifies the rule; the suffix tells you which wording is current for your tax year.Where does the IRS publish the official business rules?
Does e1099f require me to understand any of this?
Not tax advice. This is general information about IRS procedures and the IRIS business-rule catalog as published for TY2025 v1.4; rule numbers, wording, and severities can change as the IRS updates IRIS, and the official IRS publications are authoritative. Consult a tax professional for your situation.