Xmitly checks a FROI or SROI against the jurisdiction ruleset in force on its effective date — while the transaction is still in your claims system, and still cheap to fix.
Illustrative. Synthetic claim, synthetic errors — no transaction shown here was ever transmitted to a jurisdiction.
California logged 4.6 million acknowledgement records in 2024. Across FROI and SROI, three percent came back rejected and a further seven percent were accepted with errors — roughly 450,000 defective transactions, in one state, in one year.
Source: California DWC, WCIS Report Table 8. Each square is one percent.
Getting a file to a jurisdiction is solved, and has been for years. What isn’t solved is knowing, at the moment you build the transaction, whether it will survive that jurisdiction’s edit rules — which are versioned, effective-dated, and different in every state.
So you transmit, wait, read an acknowledgement, work out which rule you broke, fix it, re-file. Every cycle costs days. On a late filing, days cost money, and the clock never stopped running.
Jurisdiction-neutral JSON. One shape, whatever state you file in.
And says so explicitly when it cannot determine that from what you sent, instead of guessing.
The version effective on the filing’s own date — not today’s version, when those differ.
Field level, each one carrying the rule that produced it.
Anything marked as verified against a regulator would need a regulator’s evidence. There isn’t any yet, so nothing claims it.
| Component | State |
|---|---|
| Canonical claim model, jurisdiction abstraction | Built |
| Versioned, effective-dated rules engine | Built |
| Sandbox with simulated acknowledgements | Built |
| Colorado requirement tables loaded | Not yet |
| IAIABC XML serialisation and batching | Not yet |
| Verified against a Colorado test acknowledgement | Not yet |
| Production transmission | Disabled |
Xmitly is not approved, certified, endorsed by, affiliated with, or authorised by the Colorado Division of Workers’ Compensation, the IAIABC, or any other regulator. Colorado EDI vendor testing has not begun.
No transaction from Xmitly has ever been sent to a jurisdiction. Production transmission is disabled in code and cannot be reached with a sandbox key. Every acknowledgement in the sandbox is generated locally and labelled SIMULATED SANDBOX ACKNOWLEDGEMENT.
Where a requirement has not been implemented from authoritative source material, the engine returns AWAITING_AUTHORITATIVE_RULESET rather than a guess. A validator that guesses is worse than no validator, because it lets you believe an unreviewed filing was compliant.
I’m looking for claims software vendors, TPAs and carriers who file FROI and SROI and have an opinion about what actually goes wrong — particularly anyone working through Colorado’s R3.1 cutover, and what your acknowledgement traffic looks like since July.
There is nothing to buy. I’m trying to find out whether the problem I think exists is the problem you have.
Johnw@xmitly.com