About & Methodology
Who built AR Guide, where the data comes from, and how everything is verified before it is published. If you depend on this data to fix revenue leaks, you should know exactly how it was produced.
Who we are
Built by revenue cycle analysts
AR Guide is built by revenue cycle analysts with 15+ years of combined experience in medical billing, denials management and accounts receivable follow-up. We have worked the payer phone lines, appealed the denials and reconciled the remittances — so the workflows here reflect how denials are actually worked, not how they look on paper.
We publish no patient data and collect none. The site is a reference tool for billing professionals — it is not medical or legal advice, and it never replaces a payer contract, a plan document or your billing team's policies.
Reference data
Where the codes come from
CARC, RARC and group-code descriptions are taken directly from the official ASC X12 published code lists ( x12.org). The official description text is never edited, and each record carries the date it was last checked against the source — currently Aug 15, 2026. If the source page does not publish a version or update identifier, we say so instead of inventing one.
AR Guide's own explanations and workflows are clearly labeled editorial knowledge and are always presented separately from the official reference text.
Denial workflows
How the denial guides are created
Each denial guide is authored by our analysts as a structured workflow — what it means, what to check first, what to verify, the recommended steps, what to document, when to escalate and the QA checkpoint — rather than a generic list of denial tips. The workflow is built around the code pair on the ERA/EOB (group code + CARC + RARC read together), because the combination, not the CARC alone, tells you what the denial actually is.
- Written from practice, cross-checked against research. Guides are drafted from our analysts' AR practice and cross-referenced against editorial research leads (e.g. Muni Health, ProMBS). A research lead is a lead only — it never verifies a payer fact.
- Every guide shows its review date. Each guide carries a “Last reviewed” date and review status on the page, so you can see how fresh the workflow is.
- Payer-specific facts are never guessed. Guides never assert a filing deadline, appeal window, authorization requirement or coverage rule without verified evidence. Where a payer-specific rule would be needed, the guide says to verify it with the payer — it does not guess.
Payer contacts
How payer contact information is verified
Payer contact information changes constantly, so it is the most carefully controlled data in the app.
- Published only after source verification. A phone number, fax, payer ID, portal URL or address is published only after it is confirmed against an official source — the payer's own provider page, a government site or an official document. Nothing is fabricated, and nothing is copied from an unverified listing.
- Every value is source-tracked and dated. Each published value carries its source, the verification method used (e.g. official web page, archived snapshot of an official page) and the date it was last checked — shown on the page as “Verified / Last verified”.
- Stale data is demoted, never hidden. A “Verified” badge only appears when a source and verification date exist, and records older than the freshness threshold are automatically labeled “Expired” instead of verified. Missing values render as “Not yet verified” — we never fill the gap with a guess.
- State- and plan-scoped data stays scoped. A number verified for Texas Medicaid is never silently substituted for another state. Scope is part of the record.
Keeping it accurate
Report an error — you are a validator too
Every payer contact page and denial guide includes a way to report outdated contacts or incorrect workflows. A report never changes the published value directly — it creates a review item that our team investigates, so a single bad report can't corrupt the data for everyone. We rely on users like you to flag what changed; that is how the database stays current.
Verification standard: Note