Skip to main content
AAtlas
See a live renewal
Module · EDI

834 files, shipped — with ACK reconciliation.

An 834 is the enrollment file carriers need every time you add, change, or term a member. Every carrier wants a slightly different flavor of it — and rejects the rest. Atlas generates the file from your enrollment record, validates it against each carrier's companion-guide configuration, and ships it via SFTP. When the carrier sends back a 999 (or legacy 997), Atlas parses it — including AK3 segment-level errors and AK4 element-level errors — and reconciles against the originating outbound transmission automatically.

See a round-tripBack to Atlas overview
Pick your rail
Velora productVelora EDI
Or plug inEmpyrean · BenefitMall · Softheon · Ideon EDI

Velora EDI generates 834 files from carrier-specific companion-guide configuration, ships via SFTP, and parses inbound 999 ACKs (AK3/AK4 error detail) and 277 / 277CA claim-status responses (per-claim STC categories — accepted, pending, rejected, finalized — matched back to outbound by TRN02) directly into the originating transmission record. Prefer your existing Empyrean / BenefitMall / Softheon / Ideon pipeline? Atlas hands off the enrollment event to them via webhook — same outcome, different rail, no dual bookkeeping.

What EDI does

Electronic enrollment without the vendor middleware.

Generate

Atlas reads the enrollment state from Ben Admin (or your import), builds the 834 with the fields each carrier expects, applies carrier-specific companion-guide quirks (loops, segments, dependent linking), and writes the file.

Validate

Every file runs through structural validation plus the carrier-specific rules in its companion-guide configuration before it leaves. No rejected batches landing in a producer's inbox two weeks after OE.

Ship + reconcile

SFTP to each carrier's dropbox today (AS2 on the roadmap). Built-in monitoring of connection and delivery confirmation. Inbound 999 ACKs are parsed (AK1/AK2/AK3/AK4/AK5/AK9), matched to the originating outbound by group control number, and the source transmission flips to ACKNOWLEDGED / ACKNOWLEDGED_WITH_ERRORS / REJECTED with line-by-line error detail.

Capabilities

Every carrier, every quirk.

01

Carrier companion-guide configuration

Each carrier's 834 has its own loop/segment quirks. Atlas stores the companion-guide rules per carrier as configuration the generator reads at file-build time — so a new carrier or a guide change is a config update, not an engineering project. Aetna, UHC, Cigna, BCBS, Humana, Kaiser, Guardian, Principal, MetLife, Lincoln, Sun Life, Anthem and others ship with starter configurations; new carriers go in inside ~5 business days from companion guide.

Structural + companion-guide validation
02

Daily, weekly, or event-driven

Most carriers accept weekly full-file or daily deltas. Some prefer event-driven (new-hire, termination, qualifying-event). Atlas handles all three modes — per carrier, per client.

03

999 + 277 inbound reconciliation

Both response files parse today. 999 (technical ACK): AK1 group code, AK5 transaction code, AK3 segment errors with loop identifier, AK4 element errors with copied value, matched to the originating outbound by group control number; status flips to ACKNOWLEDGED / REJECTED with the error trail attached. 277 / 277CA (claim status): per-claim STC category + status code, payer name, patient / subscriber / provider names, TRN trace numbers matched back to the outbound transmission by control number. POST /api/v1/edi/transmissions/{ack,status-277} ingest either flavor; the X12 family is detected from ST01.

Live · 999 / 997 / 277 / 277CA
04

Full-file audit reconciliation (roadmap)

The intended end-state: monthly carrier full-file comes back, Atlas diffs against Atlas's enrollment of record, and orphaned enrollments, mis-tiered dependents, wrong effective dates surface as deltas with one-click correction files. Today the diff workflow is manual against the stored return payloads.

05

820 premium-payment generator

X12 005010X218 generator — POST /api/v1/edi/820/generate accepts payer + receiver + total + per-employee remittance lines (memberId / name / amount / period / policy) and renders the file with BPR / TRN / N1*PR / N1*PE / per-EE ENT loops with NM1 + RMR detail. The generator handles the most common broker→carrier flow today; ADX adjustment loops (over/under-payments, reversals) and carrier-direct ACH wiring are the remaining roadmap items.

Live · 005010X218
06

No EDI middleware vendor fees

If you're currently paying BenefitMall, Empyrean, or Softheon for EDI middleware, Atlas's outbound 834 generator + SFTP shipping replaces that layer for the supported carriers. Direct carrier connections, no per-transmission middleware billing.

Within Atlas

EDI is Ben Admin's carrier-facing side.

EDIdoesn’t stand alone — it’s the shipping layer for enrollment data. It reads from Ben Admin and HRIS, validates against the carrier’s companion-guide configuration, ships via SFTP, and reconciles inbound 999 ACKs (AK3 / AK4 error detail) and 277 / 277CA claim-status responses (TRN-matched back to the originating outbound with per-claim STC status). Surface-up into Billing Recon is the remaining roadmap item.
  • Ben AdminEnrollment-of-record source
  • HRISEmployee demographic feed
  • Billing Recon820 payment files, premium reconciliation
  • Broker CompCommission reconciles vs enrollment shipped
Pre-send
structural + companion-guide validation

Every 834 runs through structural validation plus the carrier's companion-guide rules before it leaves the SFTP layer. The industry's usual pattern (fire file, hope, reconcile rejects days later) gets inverted at the local validation step: most rejectable issues are caught locally, with the line that failed, before a transmission is attempted.

Pilot-phase benchmark· Reference customers launching Q2 2026 · ask for a reference call
FAQ

Questions brokers actually ask.

Which carriers are supported?
The companion-guide engine ships with starter configurations for Aetna, UHC, Cigna, BCBS (multiple state plans), Humana, Kaiser, Guardian, Principal, MetLife, Lincoln Financial, Sun Life, Anthem, and others. Companion-guide configuration is data, not code, so a new carrier or a guide change is a configuration update — typically inside ~5 business days given the guide.
Is this a full EDI gateway or a subset?
Honest framing: today it’s an outbound 834 generator with SFTP shipping, validation, transmission logging, inbound 999 (technical ACK) parsing back to the source transmission with line-by-line error detail, inbound 277 / 277CA (claim status) parsing with per-claim STC status matched back by TRN02, and an 820 (premium payment) generator. AS2 transport is roadmap. Outbound 834 + 999 + 277 reconciliation + 820 generation replaces the most expensive part of Empyrean / BenefitMall / Softheon for the supported carriers; the rest of those vendors’ surface area lands as we ship.
What about HIPAA 820 premium payments?
The 820 generator (X12 005010X218) ships today — POST /api/v1/edi/820/generate renders the file from a structured payload (payer + receiver + total + per-EE remittance lines). ADX adjustment loops and carrier-direct ACH wiring are the remaining roadmap items; the broker-to-carrier remittance flow is live.
How do connections to carriers actually work?
SFTP today (user/pass or SSH key). AS2 (certificate-based, signed and encrypted) is on the roadmap — the transport interface accounts for it but the AS2 implementation is not in production yet. For carriers that only accept secure portal upload, the today-state is a one-click upload workflow on the operator side.
What if a carrier changes their companion guide mid-year?
Companion-guide rules are configuration, not code. When a carrier publishes a change, the configuration entry is updated — typically inside 10 business days of the published guide, ahead of carrier enforcement dates.
How are discrepancies resolved?
Today: 999 (technical) and 277 (claim-status) return payloads are parsed and matched back to the originating transmission, with per-row STC / AK error detail surfaced for manual review. The target end-state — automated delta detection against Atlas’s enrollment of record, suggested correction (retroactive term, effective-date shift, tier reassign), one-click apply-and-re-send — is the remaining roadmap item; the parsers it depends on now ship.

Ship your first 834 next Tuesday.

We'll configure a sandbox connection to one of your carriers, generate a real 834 from your enrollment data, and walk you through the ACK reconciliation on the return file.

Request a walkthroughAll modules