Technical Deep-Dive: Filing 94,000 W-2Gs Through IRIS With Zero Rejections

For tax operations leads, controllers, compliance officers, and engineering teams evaluating IRIS A2A filing platforms.

In tax year 2025, a Southern California tribal casino partnered with Morado to file 94,000+ W-2G information returns through the IRS Information Returns Intake System (IRIS). Across roughly twenty production transmissions, every batch was accepted by the IRS: Accepted or Accepted With Errors, never Rejected. Every artifact (original spreadsheets, canonical normalized data, transmitted XML, IRS receipts, and 94,000 individually generated recipient and payer PDFs) was preserved, indexed, and delivered to the operator through a secure cloud portal.

This is the technical companion to the short case study. It walks through the pipeline stage by stage, names the IRS business rules we encoded, lists the edge cases we caught, and lays out the lessons earned at scale. If you are a controller or tax operations lead at a casino, sportsbook, racetrack, or tribal gaming enterprise, or an engineer evaluating IRIS A2A vendors, this is what good looks like at 94,000 records.

Hero stats

Customer overview

The operator came to Morado in early 2026 with a year of accumulated W-2G obligations and a hard regulatory deadline. They needed a partner that could ingest messy spreadsheet data, validate it against the IRS schema and business rules, transmit directly to IRIS, and deliver winner-ready PDFs at scale, without leaving a single-digit-staff finance team to triage rejections one batch at a time.

The challenge

A regional tribal casino had a year of W-2G obligations the size of a small bank's. Tens of thousands of slot jackpots, table game wins, and other reportable gaming events. Each with a winner identity, a TIN, an address, a wager type, a date, and a payout amount. Each row, by law, has to be reported to the IRS on Form W-2G, and a copy has to be furnished to the winner.

For a single-digit-staff finance team, that's a logistics problem with three teeth.

Volume. 94,000 is too many for any spreadsheet workflow that ever has a human in the loop. One stray apostrophe, one ZIP code that arrived as a float, one transaction ID with 21 characters instead of 20, and the IRS rejects the whole submission. Or worse, accepts it with errors that cascade into B-notice penalties next year.

Schema rigidity. The IRS IRIS system does not forgive. Its XSD (Tax Year 2025, schema version 1.1) is a thicket of element ordering, allowed character classes, length limits, and conditional requirements. The companion business rules layer (FS1H001, SHAREDIRFORM014, SHAREDIRFORM023, SMF027, TMFST002_001, and dozens more) layers semantic checks on top: TIN/name matching against IRS records, transmitter-vs-issuer separation, unique RecipientAccountNum within a submission, ATS-only versus production-only TIN prefixes. Each is a tripwire. A vendor that doesn't speak this language fluently will get a casino's filings rejected at scale.

Distribution. Even if filing succeeds, the casino still has to physically (or electronically) furnish a Copy B/C/2 to each winner and retain a Copy D for its own records. 94,000 jackpots means 94,000 PDFs, structured by copy type, distributed cleanly. Cloud functions and standard click-to-generate tools time out long before they finish.

This is the work Morado is built for.

The approach

Morado's pipeline is end-to-end IRS filing. Not pre-processing, not data cleanup, not a thin SaaS wrapper around an Excel template. The casino's raw spreadsheets entered Morado, and accepted IRS filings came out the other side, with every artifact preserved.

The architecture, stage by stage:

1. Ingestion. XLSX/CSV/PDF bundles uploaded to a project workspace. Title rows auto-detected. Multi-sheet workbooks decomposed.
2. Header categorization. A human-in-the-loop step where the operator confirms which spreadsheet column maps to which semantic concept (TIN, recipient name, address line 1, wager type, etc.). Heuristic auto-suggestions catch >90% of headers; the operator confirms or overrides.
3. Vendor matching and consolidation. Where multiple data sources exist (W-9s, vendor master files, payment files), Morado reconciles them with a defined priority (W-9 > Vendor Master > CSV) and tracks the source of each field for audit purposes.
4. Form type routing. For single-form-type batches (such as a W-2G-only filing), Morado offers a "Path C: All Same Form Type" option that bypasses LLM inference entirely. No PII ever touches an external model. For mixed batches, the operator confirms the form type per row.
5. Field mapping. Semantic categories are mapped to IRIS XSD field names with a human-in-the-loop confirmation step.
6. Pre-flight validation. The validator that does the work most other vendors skip. (Detail below.)
7. Canonical normalization. Dates, names, ZIP codes, money fields, TINs, and addresses are normalized into a canonical JSON representation stored in the operator's project workspace.
8. XML generation. IRIS A2A XML is built directly against the TY2025 v1.1 schema. Every transmission is locally validated with xmllint --schema before it leaves Morado infrastructure.
9. Direct IRS submission. mTLS to the IRIS A2A endpoint, OAuth2 JWT bearer (RS256), Morado's transmitter TCC on the wire, the casino's TCC as the issuer. No middleman.
10. Status polling. Receipt IDs are polled directly against IRIS until the IRS returns a final disposition.
11. Distribution. All 94,000 recipient PDFs (Copies 1, B, C, instructions, 2) and 94,000 payer PDFs (Copy D) generated and delivered through a secure cloud portal to the operator's tax operations team.
12. Audit trail. Every artifact preserved in object storage at a deterministic path, retrievable for years.

That's the surface. The depth, what makes the difference between "submitted" and "accepted at scale," is in the validation, the rule encoding, and the edge-case handling.

Differentiator #1. Pre-flight Excel validation that catches what the IRS would reject

Most filing vendors will accept a malformed spreadsheet, transmit it, and let the IRS tell you what's wrong. By then, you've consumed your transmission window, owe the operator a re-file, and possibly created a duplicate filing problem (which has its own correction overhead and penalty exposure).

Morado validates before transmission. For this engagement we built a dedicated W-2G Excel validator (~400 lines, against the raw XLSX) that flags every issue class the IRS schema or business rules would catch, plus a long tail of operator-specific anomalies. A non-exhaustive list of what it caught:

Identity and TIN:

• SSNs missing leading zeros (a recurring Excel float-formatting hazard)
• TINs with non-numeric characters or wrong length
• ITIN prefixes (9XX) recognized as valid where naive validators reject them
• Placeholder 000000000 recognized as a valid "no TIN provided" indicator in production
• Test prefix 000 allowed in ATS, downgraded to a warning in production (the IRS treats these as Report Error, not Reject)

Names:

• Multi-word name detection: 5,337 names had four or more words; 1,010 were exactly four words
• Suffix detection: JR, SR, II, III, IV correctly extracted to the IRS SuffixNm element rather than concatenated into the last name
• Compound first-name detection via double-space delimiter (the operator's spreadsheets used ANA PATRICIA FLORES RODRIGUEZ to mark the first/last boundary on Hispanic two-part names, a convention Morado now natively recognizes)
• Apostrophe stripping (D'ERCOLE → DERCOLE) per IRS character-class rules

Addresses:

• Periods (ST., P.O.): disallowed
• Hash symbols (#): disallowed
• Double spaces: collapsed
• Apostrophes: stripped
• Allowed character class enforced: [A-Za-z0-9 \-/]

ZIPs:

• Excel float artifacts: 92127.0 → 92127
• Padding to 5 digits for under-length ZIPs (a frequent issue with ZIPs starting with 0)

Dates:

• ISO datetime stripping: 2025-01-17 22:43:00 → 2025-01-17
• M/D/YY → YYYY-MM-DD normalization

Money:

• Excel - as a "no value" indicator → 0.00 (instead of currency.js returning NaN and silently producing "NaN" in XML)
• Final NaN guard on every money field at the formatter level

Transactions and uniqueness:

• 119 duplicate transaction IDs flagged for review
• 17 transaction IDs over the 20-character IRIS limit
• 16,186 same-day multi-win combinations surfaced for the operator to confirm intentional vs. duplicate
• 196 Table Games JP rows flagged for client review on data-quality grounds

Geography:

• 1 invalid state code caught
• US/foreign address routing (USAddressGrp vs. ForeignAddressGrp) auto-applied

The operator received the validator output as a set of CSVs they could open in Excel: validation findings, same-day-wins, long-names, problematic-names lookup. Every issue was triaged before a single record entered IRIS.

This is the difference between a vendor that lets you file and a vendor that makes sure your filing succeeds.

Differentiator #2. IRS rule encoding, not IRS rule documentation

Most filing tools say "we support IRIS." That usually means "we know how to call the API." It rarely means "we've encoded the business rules." Morado has, and the difference shows up the first time you submit at volume.

Some of the rules we've internalized into validation, generation, and submission logic:

• FS1H001. RecipientAccountNum must be unique within a submission. We auto-populate it as the record index (1, 2, 3, ...) so duplicate SSNs across records (a casino has many of these, one winner with many jackpots) never violate uniqueness. This also makes corrections trivial: every record has a stable identifier.

• SHAREDIRFORM014. Name/TIN matching against IRS records. We normalize names (apostrophe stripping, suffix extraction, casing) to maximize match probability and surface mismatches as operator-actionable warnings rather than silent rejections. In this engagement, 43 unique names were flagged across all batches as TIN/name mismatches. These are Report Error findings: the IRS still accepts the submission, the operator follows up via B-notice, but the surfacing matters.

• SHAREDIRFORM023. TIN required on every record. The placeholder 000000000 is the IRS-accepted "no TIN provided" indicator and Morado emits it for genuinely missing TINs without rejecting the whole submission.

• SMF027. In ATS (test) submissions, Test Code "T" requires 000-prefixed TINs. In production, 000-prefixed TINs are downgraded to a warning. Morado switches behavior automatically based on IRS_ENV. Operators never have to remember which mode they're in.

• TMFST002_001. Transmitter vs. Issuer TCC mismatch. The transmitter (Morado) is not the issuer (the casino, with its own TCC). Most vendors conflate these; we keep them strictly separated, with the casino's TCC populating IssuerGrp and Morado's TCC populating TransmitterGrp.

• XSD element ordering. IRS XSDs require strict element order. RecipientAccountNum is a sibling of RecipientDetail, not a child. PersonFirstNm → PersonMiddleNm → PersonLastNm → SuffixNm is the canonical name order. Get any of these wrong and the schema rejects pre-transmission.

• Optional groups must be omitted, not stubbed. JuratSignatureGrp and ContactPersonInformationGrp are optional. Vendors that fall back to their own contact info as a default leak vendor identity into a customer's filing. Morado omits optional groups entirely if the casino hasn't provided the data, rather than substituting Morado's contact details.

• Receipt ID parsing. Multiple separator characters (', ", :, whitespace, >) appear around the receipt ID in the IRS XML response depending on the exact transmission path. Morado's parser handles them all.

• Status checks via POST + XML body. Per IRS Pub 5718 Table 3-4, status checks are POST with an XML body, not GET with query params. Many vendors get this wrong on day one and have to rebuild it.

That's not a feature list. That's compliance reading internalized into code, validated against ATS, and proven in production.

Differentiator #3. Real-world edge case handling

The IRS XSD is a clean specification. Real spreadsheets are not. Here are concrete edge cases this engagement surfaced and Morado now handles natively:

These aren't theoretical. These are 94,000 real records, surfaced through real validation, and solved against the live IRIS system.

Differentiator #4. Direct IRS submission as a transmitter

Many vendors are not transmitters. They are resellers: they hand your XML to another vendor's transmitter and inherit that vendor's reliability, latency, queue, and incident response.

Morado is on the IRS list as a Transmitter A2A. Submissions go directly from Morado infrastructure to api.www4.irs.gov over mTLS, authenticated with an OAuth2 JWT bearer token signed RS256 with our private key. Standard SSL cert from a regular CA for the mTLS layer; the same private key signs JWTs.

What that means in practice for the casino:

• No queue behind another vendor. When you submit, you submit. The latency between "click file" and "IRS receipt" is bounded by the IRS, not by a middleman.
• Real incident response. If IRIS has an issue, we know. We don't have a vendor between us and the IRS.
• Per-batch status visibility. Every batch has a receipt ID. Status checks return live IRS dispositions: Processing, Accepted, Accepted with Errors, Rejected. Per-batch.
• Test environment parity. ATS (api.alt.www4.irs.gov) and production are both first-class. The same code path serves both, switch with one environment variable. We test fixes against ATS before production releases.

Differentiator #5. PII-aware processing

A 94,000-record W-2G file is a 94,000-SSN file. The privacy posture of the vendor handling that data should not be an afterthought.

Morado was built with PII separation as a design constraint:

• Path C, All Same Form Type. When a batch is single-form-type (W-2G in this engagement), Morado skips LLM inference entirely. No row data is sent to any external model. Form type is asserted up front by the operator and used as the routing key.
• Header categorization is local. Header names (not row data) are run through deterministic heuristics. Where ambiguity exists, the operator resolves it interactively. Row data does not leave the operator's session.
• Storage is per-project, per-user. Every artifact is stored at a deterministic, user-scoped path: {userId}/{projectId}/{sessionId}/.... Row-level Postgres RLS (Row Level Security) enforces it.
• No row-level data in observability. Logs, metrics, error reports are scrubbed at the boundary.
• PII anonymization tooling. When the casino needed test data for ATS submissions, we built an anonymizer that swapped first/last names and replaced SSNs with valid 000-prefixed test TINs in eleven test records. The same tooling is available for any operator.

Differentiator #6. Audit trail you can hand to an auditor

Every batch transmitted to the IRS produces six artifacts, all retained:

filing-uploads/
  {userId}/
    {projectId}/
      {sessionId}/
        original.xlsx                             ← Operator's source data
        canonical-returns.json                    ← Normalized canonical
        payer-config.json                         ← Issuer / payer metadata
        submissions/
          {submissionId}.xml                      ← What we sent to IRIS
          submission-response.xml                 ← IRS receipt
          status-response.xml                     ← Final IRS disposition

When an IRS examiner asks the casino in 2028 to show what was filed for tax year 2025, batch 14, the answer is six retrievable files at a stable, addressable path.

When the operator needs to file a correction (wrong amount, wrong TIN, name update), Morado already has the original RecipientAccountNum and receipt ID. Corrections are a structured update against a known prior submission, not a guess.

Differentiator #7. Cloud portal delivery for 94,000 PDFs

The casino didn't just need IRS filings. They needed individual PDFs to retain (Copy D) and to furnish to winners (Copies 1, B, C, instructions, 2). At 94,000 records, that's ~188,000 PDFs.

Morado generated all 94,000 recipient PDFs and all 94,000 payer PDFs and delivered them through a secure cloud portal to the operator's tax operations team. Two clearly labeled folders per batch:

Payor/        ← Copy D only (1 page per record)
Recipient/    ← Copies 1, B, C, instructions, 2 (5 pages per record)

PDFs are coordinate-mapped against the official IRS templates. Morado does not synthesize the form; it fills the official PDF. Field positions, font sizes, and alignment all match what the IRS expects. Winners can verify their own copies against any reference; payers can hand-audit their Copy D against any sample.

Copy A is intentionally absent. The IRS receives the electronic filing; paper Copy A is not needed and including it creates duplicate-filing risk.

How Morado compares to legacy filing tools

Comparison reflects publicly documented capabilities and Morado's direct experience with IRS-listed transmitter status as of May 2026. Vendor capabilities change; verify current state with each vendor before purchase.

Results

• 94,000+ records filed in production across ~20 batches.
• 0% rejection rate. Every batch landed as Accepted or Accepted with Errors. None Rejected.
• 43 unique TIN/name mismatches flagged across all batches as Report Error findings. The operator follows up via B-notice. (For context: these are surfaced findings, not rejections. The submissions still went through.)
• ~188,000 PDFs generated and delivered through a secure cloud portal to the operator's tax operations team.
• Six audit artifacts retained per batch. Every transmission, every receipt, every status response, addressable for years.
• Pre-flight validation surfaced 100+ issue classes before any record left for IRIS, including 119 duplicate transaction IDs, 17 over-length transaction IDs, 5,337 multi-word names requiring careful first/last/suffix split, and 16,186 same-day multi-wins flagged for operator confirmation.

In their words

"Morado caught issues in our data we didn't know were issues, transmitted every batch directly to IRIS as our transmitter, and gave us a downloadable record of every filing the IRS accepted. Zero rejections across 94,000 records. The audit trail alone was worth the engagement."

— Tax Operations Lead, Southern California tribal casino

Lessons from filing 94,000 W-2Gs

If you take one section from this case study, take this one. These are the lessons we earned filing 94,000 W-2Gs, and they apply to any casino, sportsbook, racetrack, or gaming operator on the verge of a similar volume problem.

1. The IRS doesn't reject what most vendors think it rejects.

000-prefixed TINs in production? Accepted as Report Error. All-zero TINs (000000000)? Accepted as "no TIN provided." All-nine TINs (999999999)? Accepted as Report Error. Name/TIN mismatch? Accepted as Report Error. Most "validation errors" you see in legacy filing tools are client-side over-validation that gets in the way of legitimate filings. Morado knows the difference between a hard XSD or business-rule violation and a soft Report Error finding, and treats them differently. Hard errors block; soft errors are surfaced and submitted.

2. The real bugs are in your spreadsheets, not in the IRS.

We never lost a batch to an IRS bug. We almost lost batches to:

• An Excel "no value" dash interpreted by currency.js as NaN, written to XML as the string "NaN".
• A ZIP code formatted as a float (92127.0) because Excel converted it.
• An ISO datetime where a YYYY-MM-DD date was expected.
• An apostrophe in a last name.
• A period in an address.
• A double space anywhere.
• Compound first names without a delimiter convention.
• A 21-character transaction ID against the IRIS 20-character limit.

A vendor that doesn't validate at the spreadsheet boundary, before XML generation, will lose batches at scale. Morado validates at the boundary.

3. Transmitter and issuer are not the same thing, and many vendors get this wrong.

The IRS distinguishes the transmitter (the entity submitting the file) from the issuer (the entity actually obligated to issue the form). When a third-party vendor files on behalf of a casino, the vendor's TCC populates TransmitterGrp and the casino's TCC populates IssuerGrp. Conflating them, putting the casino's TCC in TransmitterGrp because that's where the "main" identifier seems to go, produces a TMFST002_001 rejection.

Worse: some vendors fall back to their own contact info inside JuratSignatureGrp or ContactPersonInformationGrp when the casino didn't provide it. That leaks vendor identity into the casino's filing and creates downstream confusion in IRS records. Optional groups should be omitted, not stubbed.

4. Local schema validation is non-negotiable.

Every transmission is locally validated against the IRIS XSD with xmllint --schema before it leaves Morado infrastructure. This catches every address pattern violation, element ordering bug, length overflow, and missing required field. It costs essentially nothing, milliseconds per submission.

ATS (the IRS test environment) validates the schema. Production validates the schema and runs business rules. Anything that fails ATS will definitely fail production. Anything that passes ATS may still fail production business rules, which is why pre-flight Excel validation matters even after XSD passes.

5. ATS is for test, production is for production, and you must test in ATS first.

The IRS provides ATS (api.alt.www4.irs.gov) with a separate TCC. It uses the same protocol, schema, and business rules as production. Every code change at Morado is exercised against ATS before it touches production. Casinos filing through Morado inherit this discipline whether they know it or not.

6. RecipientAccountNum is an underrated weapon.

It's optional in the schema. It's required for uniqueness within a submission (FS1H001). It's a stable identifier for corrections. Setting it to the record index (1, 2, 3, ...) on every record means every filed return has a known address. When you need to amend, you know exactly which record you're amending. Casinos who skip this step end up matching by SSN+amount+date during corrections and discover they have ambiguous records.

7. PDF generation at 94,000 records is its own engineering problem.

Coordinate-based PDF filling against the official IRS template, run at scale, is not a one-liner. We pre-process the canonical data, fill page coordinates with pdf-lib, separate copies by recipient/payer, name files deterministically, package by batch, and deliver through a cloud portal. Most filing tools don't deliver PDFs at scale at all; they hand you a CSV and let you figure out the recipient copies. Morado does the whole job.

8. The audit trail is not a feature. It's the product.

When an examiner asks the casino in 2028 to produce what was filed and what the IRS said about it, the casino should answer in seconds. Not by re-creating the file from the database. By retrieving the actual XML and the actual IRS receipt. Morado preserves both, at a stable path, indefinitely.

9. PII separation is a posture, not a checkbox.

A vendor that sends row data to LLMs for "auto-classification" is exfiltrating SSNs to a model provider. Morado's Path C ("all same form type") explicitly avoids this. Header names go through deterministic heuristics; row data stays in the operator's session. The operator can audit exactly what's transmitted, to whom, when.

10. Direct IRS connectivity beats reseller arrangements.

When IRIS has an issue, when a receipt parses oddly, when a status check returns an unexpected error code, being on the wire as a transmitter ourselves means we see it and respond. Resellers see it second-hand, days later, and respond third-hand, days after that. For a casino filing into a tax-deadline window, that gap is the difference between filed-on-time and penalty.

Frequently asked questions

Is Morado a Transmitter or a reseller? Direct IRS-listed Transmitter A2A. Submissions go directly from Morado to the IRS over mTLS. No middleman, no reseller queue.

What's the IRIS A2A schema version Morado supports? TY2025 schema v1.1 today. Morado tracks IRS schema releases and validates against the current production XSD on every submission.

How does Morado handle the FIRE-to-IRIS transition? Morado already files exclusively through IRIS for the 1099 series and W-2G, and through MeF for 1042-S. FIRE retires December 31, 2026. Read the full FIRE-to-IRIS transition guide →

Can Morado handle 1099 forms beyond W-2G? Yes. IRIS accepts the full 1099 series; Morado files all of them. Morado also files 1042-S directly via MeF.

What if my data isn't clean? That's the point of the pre-flight validation. The 94,000-record engagement surfaced 100+ issue classes before the first record was transmitted. Operators get a CSV of findings to triage in Excel before anything goes to IRIS.

What's the audit trail look like? Six artifacts per batch, retained at a stable path: original XLSX, canonical JSON, payer config, transmitted XML, IRS submission acknowledgment, IRS status response. Retrievable for years.

Does Morado handle state filing? Most states still accept Publication 1220 format alongside IRIS. Morado generates state filings in the format each state requires.

How does Morado handle PII and data security? Single-form-type batches bypass LLM inference entirely. Row data does not leave the operator's session. Storage is per-project, per-user, with row-level security enforced at the database layer. Logs and observability are scrubbed at the boundary.

What's pricing? Contact Morado for a quote based on volume and form mix.

Book a Call

A 30-minute call with a Morado engineer. Walk through the pipeline against a sample of your real data. Get every question your tax operations team has answered.

Book a Call →

If you'd rather see Morado run against your own data first, we'll set up an ATS test transmission with a sample of your real records, end-to-end, in days, not weeks. Pre-flight validation against your actual spreadsheets, surfacing every issue before transmission. The casino in this case study filed 94,000 W-2Gs with zero rejections. Your filings can do the same, for tax year 2025, and every year after.

---

Morado is an end-to-end IRS filing platform for 1099, 1042-S, and W-2G information returns. Direct IRIS A2A transmitter. Direct MeF connectivity for 1042. Production-certified. Built for operators who care about getting it right the first time.

Morado's IRS Transmitter A2A status is publicly listed in IRS Publication 5718 (the IRIS Implementation Guide).

Read next

• Casinos and tribal gaming: how Morado serves W-2G volume →
• The Complete Guide to the IRS FIRE to IRIS Transition (2026) →