Skip to content
Payerworks
Talk to us

A clearinghouse, built by the people who bill on it

Claims in. Money back. Nothing lost in between.

Payerworks moves claims, remittances, eligibility and claim status between the teams that bill and the plans that pay, and keeps every file it touched so that nothing a payer said can go missing.

Talk to PayerworksTry it in your browser

POST /v1/remittances/explain

{
  "check": "EFT-20261018-01",
  "claims": 2,
  "second_claim": {
    "reference": "PW-1002",
    "paid": 0,
    "verdict": "denied",
    "verdict_words": "Refused: the payer paid nothing. The refusing adjustment is CO-50 (Non-covered: not deemed a medical necessity).",
    "remarks": [
      {
        "code": "N115",
        "words": "The decision was based on a Local Coverage Determination (LCD).",
        "label_source": "paraphrase"
      }
    ]
  }
}

Computed on this page by the engine the API runs, from a sample file.

  • X12 005010, loop by loop
  • A HIPAA business associate
  • Encrypted under keys we manage
  • Safe retries, one key

The loop

One connection out. Every answer back, in words.

Headless by design: everything Payerworks does with a file is an API call, and the screens are optional. Get a test key from the Developers page and send your first claim to the sandbox payer today, with no call and no contract.

  1. Your system

    portal, EHR or billing app

    claims

    the fix, in words

  2. Payerworks

    checks, writes, reads, explains

    837P

    999 · 277CA · 835

  3. The payer

    or its gateway

Out

  • Checked against the 837P and the code sets
  • Written as an 005010X222A1 interchange
  • Tracked under your own claim reference

Back

  • 999: was the file taken
  • 277CA: was each claim taken
  • 835: what was paid, and why not

See it work

Real answers from the engine, not mockups

Each screen is Payerworks reading one of its own sample files, or running its samples through the sandbox payers, on the Try it page, captured as it answered.

payerworks.com/tools
Payerworks explaining a sample remittance: one claim paid, with its amounts and its contractual adjustment, and one claim denied as not medically necessary, with its remark code in words.

An 835 read claim by claim: what happened to each in words, billed, allowed, paid, what the patient owes and what was written off, and every code explained.

Open it live

What moves through it

Every transaction a claim lives on

  • 837P

    Claims

    A professional claim written loop by loop from the record that produced it and checked before it leaves. Today you send the file on your own connection; once a payer’s route opens, Payerworks sends it and tracks it under its reference to the day it pays.

  • 835

    Remittances

    A remittance read line by line, matched to its claim by the identifiers the payer sent back, and the plan behind each line said in plain words before anyone posts a dollar.

  • 270 / 271

    Eligibility

    The benefits question asked the way the payer answers it, the whole answer kept, and the parts that matter read out for the person who has to decide.

  • 276 / 277

    Claim status

    The status question written and the payer’s answer read: where the claim stands, in words, with the next step. Asking a payer ourselves, and the Medicare contractors that answer only in batch, waits on each payer’s route opening.

  • 999 / 277CA

    Acknowledgments

    Every accept and every reject translated from the code into the fix, on the claim it belongs to, so a rejection is work with a name instead of a file nobody opens.

The specification

What a clearinghouse owes you

We spent years as a customer of clearinghouses before we built one. This is the list we kept of what we were owed and did not get. It is the specification, and what Payerworks is building toward: each line becomes true for a payer as that payer’s route opens.

  • Every answer, pushed

    A remittance, a status or an acknowledgment reaches your system when it arrives, with an exact cursor, never on a timer you have to poll.

  • Your reference, round trip

    The claim leaves with your identifier and the answer comes back carrying it, so matching is a lookup, not a guess.

  • Remittances that follow you

    A payer authorizes one receiver for your remittances. Moving it is a revocation and a re-enrollment, and we will own that move per payer and per billing entity, with a receipt.

  • Status where the phone is the only other way

    The Medicare contractors answer claim status only in batch, which is why most clearinghouses mark them unsupported. We will ask them the way they answer.

  • A payer list that is never blank

    Every payer row names where its fact came from and when. A payer we cannot route says so, instead of an empty cell.

  • Enrollment you can correct

    A wrong identifier on an enrollment is corrected on that row, by you, without a ticket and without losing the rest.

  • Failures with a type and a retry

    A payer timeout, a transient refusal and a bad file are three different things, named as three different things, and the ones that deserve a retry get one.

  • Every raw file, archived

    What the payer sent is kept as the payer sent it. A dispute years later is answered from the file, not from memory.

Try it

Paste a file. See it explained.

Drop in an 835 remittance, a 999 or 277CA rejection, a 271 eligibility answer, a 277 claim status answer or a claim, and the engine explains it on the spot: what was paid and why not, what to do next, what the plan covers, where the claim stands, what would get it refused before it leaves. Or run the sandbox payers and write an appeal letter from your facts. It runs in your browser, so nothing you paste is uploaded.

Try it in your browserGet a test key

Three audiences

Who it is for

  • Billing teams and practices

    One connection to every payer you bill, with the route and the enrollment tracked for each one.

    For billing teams

  • Payers and networks

    A trading partner that sends clean files on your terms, reads your acknowledgments, and never asks twice for an answer you already gave.

    How a payer connects

  • The people who protect the data

    Encryption under keys we manage, access by role, and an audit trail with no patient detail in it.

    Security and privacy

Honestly

Where Payerworks is today

Payerworks is opening in stages, and the books of the billing company that built it move first.

Receiving is built: remittances, acknowledgments and status answers are read by the same rules that read every file we already handle, on an endpoint of our own that opens to each trading partner by agreement.

Sending is not open yet: Payerworks is working toward its first registrations with the Medicare contractors. A payer lane moves onto Payerworks only once Payerworks receives for it, one payer and one billing entity at a time, and never before.

The engine is an API today: validating claims and writing 837P files; writing 270 and 276 questions and explaining every 271 and 277 answer; reading remittances and acknowledgments; and saying every rejection and denial as the next step, with appeal letters written from your facts, are calls any system can make with a key. The API writes the files and you send them on your own connection. The Developers page lists every call.

A developer can start alone: a test key comes from the Developers page, and sandbox payers answer test claims with a 999, a 277CA and an 835, eligibility questions with a 271 and status questions with a 277, the claims sandbox’s answers posted to your webhook if you set one. It is for invented data only; a live key needs a signed business associate agreement, and nothing reaches a real payer through the API until that payer’s route is live.

New trading partners connect by agreement. If you are a payer, a network or a service vendor, the Connect page says what we need from each other.

Talk to us

What happens next

  1. 1

    A person at Payerworks reads what you sent, usually within a business day.

  2. 2

    One reply by email names the next step: our trading partner details, where each of your payers stands, or a key for the API.

  3. 3

    Nothing follows unless you answer. There is no sequence behind this form.

Or write to hello@payerworks.com.

Talk to Payerworks

Who you are and what you want to connect. A person replies by email, usually within a business day, and there is no follow-up sequence.

Used to reply to you and for nothing else.