Medical Billing Software for DME Billing Companies

Short answer

DMEPOS billing runs in a separate Medicare contracting system from physician and hospital claims. Four regional DME MACs process all fee-for-service DME claims — Jurisdictions A and D handled by Noridian, B and C by CGS — each with its own local coverage determinations, supplier manual, and policy articles. Claims use HCPCS Level II alphanumeric codes, not CPT codes, and the correct code for each item is verified through the PDAC contractor's DMECS system. Modifiers do heavy work: KX attests that medical necessity documentation is met, GA/GY/GZ govern advance beneficiary notice situations, rental-versus-purchase modifiers (RR, NU, UE) set the payment category, and capped-rental progression modifiers (KH, KI, KJ) price each month of billing. Documentation adds an audit-exposure layer physician billing does not have: a standard written order, proof of delivery, and for many items a required face-to-face encounter. A billing company managing multiple DME suppliers needs software that surfaces CARC and RARC denial reasons per line, tracks ERA remittances at the line level, and keeps work queues separated by supplier. See the CMS DMEPOS payment policies page and the Noridian DME MAC Jurisdiction D supplier resource hub.

Why DMEPOS billing is different from physician billing

DMEPOS billing diverges from the physician and outpatient billing most revenue cycle software is built around in three structural ways: the code set, the contractor routing, and the documentation it takes to get paid.

Coding. DMEPOS claims use HCPCS Level II codes — a letter followed by four digits — rather than CPT codes. The PDAC contractor, through the DMECS lookup system, is the authority for which HCPCS code correctly describes a given item. In product categories where CMS requires coding verification review, a claim for a product not on the PDAC Product Classification List denies regardless of documentation quality. Billers coming from physician practices have to learn a different code set, modifier stack, and fee schedule.

MAC routing. Physician claims route to a Part B MAC by provider location. DME claims route to one of four DME MACs by the beneficiary's residence, not the supplier's location. A single supplier shipping nationwide deals with all four jurisdictions, and each jurisdiction's LCDs, policy articles, and supplier manual are the operative rules — not the physician MAC serving the same state. A billing company with multi-state DME clients manages several overlapping policy environments at once.

Documentation. A physician claim turns on the clinical note and the order. A DMEPOS claim also requires a standard written order, often a face-to-face encounter, and for delivered equipment a signed and dated proof of delivery. Missing any one triggers a denial unrelated to whether the equipment was medically appropriate, which makes DMEPOS more operationally intensive per claim.

Sources: CMS HCPCS general information, CMS DME MAC jurisdiction pages, PDAC DMECS coding system.

The four DME MAC jurisdictions

CMS contracts DME MAC services through two organizations across four geographic jurisdictions. Every DMEPOS supplier must know which jurisdiction covers its patients, because LCDs, policy articles, and supplier manual chapters differ by jurisdiction even when national coverage policy is the same.

Noridian was re-awarded both the JA and JD contracts in early 2025. Assignment follows beneficiary residence: a Texas supplier shipping a CPAP to a patient who lives in New Jersey submits that claim to JA, not JC.

Billing companies with suppliers serving dispersed patient populations should confirm jurisdiction routing in their clearinghouse configuration. Routing to the wrong MAC is a technical denial a clean claim should never generate.

Sources: CMS Who are the MACs — JA, CMS Who are the MACs — JC, CGS Jurisdiction B, Noridian re-award announcement.

HCPCS Level II coding and the PDAC

HCPCS Level II codes are the billing language for DMEPOS. They cover equipment, supplies, orthotics, prosthetics, and drug infusion items that CPT codes do not address. CMS maintains and publishes the code set, but product-level coding decisions belong to the PDAC.

The PDAC (Pricing, Data Analysis, and Coding contractor), currently operated by Palmetto GBA, assigns HCPCS codes to specific DMEPOS products and maintains the DMECS database. In categories where CMS requires coding verification review, manufacturers and distributors submit an application and the PDAC publishes verified products on the Product Classification List within DMECS. If a supplier bills a code for a product not on that list, the claim denies. The risk sits upstream of the billing company, so billers need to check DMECS when a new product or code combination starts generating unfamiliar denials.

Coding verification is voluntary for most items but effectively mandatory in categories where CMS requires it for payment. The PDAC completes code verification reviews within 90 days of a valid application.

When a denial reason points at HCPCS code validity rather than documentation, the root cause may be a product not yet verified through PDAC rather than a billing error. That diagnosis requires a DMECS lookup, not a rebill.

Sources: PDAC DMECS system, CMS HCPCS information, Noridian PDAC guidance.

Modifiers that carry the claim

DMEPOS lines carry more modifier weight than most physician billing. The set divides into two families: policy compliance modifiers that tell the MAC whether medical necessity criteria are met, and transaction-type modifiers that determine how the fee schedule prices the claim.

Critical incompatibility: GA, GY, and GZ cannot appear together on the same line. A line carrying GZ and GA at once denies as unprocessable and requires correction and rebilling. Pick the right modifier before the claim goes out — a supplier cannot retroactively create an ABN.

Sources: Noridian modifier lookup and definitions, Noridian oxygen claim modifier guidance, CGS DMEPOS fee schedule chapter 5.

Documentation: standard written order, face-to-face, and proof of delivery

DMEPOS has a layered documentation structure that generates denials independent of coding accuracy. Every layer needs to be present before claim submission.

The standard written order (SWO) is the baseline and must reach the supplier before the claim is submitted. For many items, a written order prior to delivery (WOPD) is required: the completed SWO must reach the supplier before the item ships. A WOPD must be completed within six months of any required face-to-face encounter. CMS published a standardized set of order elements that applies to all DMEPOS orders.

For items on the required face-to-face encounter list, a treating practitioner must have seen the patient and documented the clinical findings that support the order. CMS first published this list in January 2022 with 46 PMD codes and seven other items, and has expanded it since.

Proof of delivery (POD) is a claim requirement, not just a business record. A valid POD must include the beneficiary's name, the delivery address, a description sufficient to identify the item (brand name, serial number, or narrative description), the quantity delivered, the date delivered, and the beneficiary or designee signature and date. Suppliers and their employees cannot sign on behalf of the beneficiary. The date of the beneficiary's signature is the date of service; if the supplier-entered date and the beneficiary date differ, the beneficiary date controls. POD records must be retained for seven years.

CMS eliminated CMN (Certificate of Medical Necessity) and DIF (DME Information Form) forms effective January 1, 2023. For dates of service on or after that date, submitting a CMN or DIF causes the claim to reject. The medical necessity requirement itself remains — it lives in the medical record and the order, not on a CMS form.

Sources: CMS DMEPOS order and face-to-face encounter requirements, Noridian standard written order, Noridian proof of delivery requirements, CMS CMN elimination notice.

Capped rental billing and the 13-month rule

Many DME items — hospital beds, wheelchairs, CPAP machines, and other equipment in the capped rental category — pay on a monthly rental basis with a hard 13-month cap on continuous use. The rules differ from both standard rentals and outright purchases, and miscoding the rental month is a persistent denial source.

For standard capped rental items (excluding power wheelchairs), the fee schedule pays 10% of the base-year purchase price in months 1–3, then 7.5% for months 4–13. Power wheelchairs pay 15% in months 1–3 and 6% in months 4–13. After month 13, title transfers to the beneficiary; Medicare then covers reasonable and necessary maintenance and servicing not under warranty, but makes no further rental payments.

The modifier sequence is KH for the first month, KI for months 2–3, and KJ for months 4–13. RR does not apply during a capped rental — it belongs to other rental categories — and the wrong modifier for the billing month generates a denial.

If the beneficiary changes suppliers during the 13-month period, the rental clock does not reset. The new supplier picks up at the same point in the sequence as the prior one. Billing companies whose clients accept transferred patients need a way to track where in the rental cycle a patient actually stands.

Continuing to bill monthly after month 13 is a common compliance failure. The system does not automatically stop the claim — billers have to know the equipment was delivered in a specific month and count forward.

Sources: Noridian capped rental items guidance, CGS DMEPOS fee schedule chapter 5, CMS DMEPOS payment policies.

The competitive bidding program

CMS runs a DMEPOS Competitive Bidding Program (CBP) that sets contract rates for certain items in certain geographic areas. Suppliers must be contract awardees to bill at the bid price for covered items in covered areas; non-contract suppliers are generally not paid for competitive bidding items in CBP areas.

CMS finalized a rule in December 2025 for the next round, effective January 1, 2026, with contracts set to begin January 1, 2028. The rule expands the program and consolidates bidding systems into a single platform called Connexion. Product categories in the final rule include continuous glucose monitors, insulin pumps, urological supplies, ostomy supplies, and various orthotic braces. CMS also moved reaccreditation to annual from every three years.

For billing companies, the practical questions are which clients bid and won contracts, which product categories are in scope in the areas those suppliers serve, and whether the billing system can tell CBP lines from non-CBP lines on the same 837P.

Sources: CMS DMEPOS competitive bidding page, CMS competitive bidding final rule fact sheet, DLA Piper CBP analysis.

Denial patterns that erode DME revenue

DMEPOS claims fail in predictable ways. Most billing-company denial volume in this specialty concentrates in six categories.

Missing documentation before submission is the most common and the most preventable. A claim without a valid SWO, a required face-to-face encounter note, or a signed POD denies at prepayment review. The gap usually traces to a supplier intake workflow that is not tied to billing: equipment ships, the POD is not scanned promptly, and the claim goes out incomplete.

Modifier errors — wrong modifier for the rental month, GA without an ABN on file, GZ when GA was correct, or RR on a capped rental item in month 5 — each produce different denial codes and need different corrective action. Billers need to see which modifier generated the denial, not just that the line denied.

Medical necessity denials under KX criteria mean the supplier billed KX but the documentation on file does not satisfy the LCD. That is a compliance exposure as well as a denial: the claim was attested as meeting criteria when it did not.

HCPCS code errors — an outdated code, a code that does not match the item's specification, or a code whose product has not passed PDAC verification in a required category — generate technical denials that billers often misread as documentation issues before realizing the code is the problem.

Capped rental overbilling — billing past the 13-month transfer, using KH in month 3 instead of KI, or resetting the clock when the patient changes suppliers — creates denials and, when systematic, OIG audit exposure.

Competitive bidding noncompliance — a non-contract supplier billing a CBP item in a CBP area — produces a denial that no appeal corrects, because the issue is supplier eligibility, not claim content.

Sources: Noridian JD DME denial and appeal resources, CMS Medicare Learning Network DMEPOS general documentation requirements.

How Medi handles DME billing-company workflows

Medi is a billing-company-first RCM platform, not an EHR. It does not auto-code HCPCS Level II, generate documentation, or ship DMEPOS-specific claim edits or PDAC lookups. What it does is organize the work billers already do across multiple supplier clients, in one place with one login.

Denial management. Medi translates CARC and RARC codes at the service line. A line denied with CARC 50 (non-covered service) because GY was correct but GA was billed needs different action than a line with CARC 4 pointing at a coordination-of-benefits issue. Billers see both on the same queue, read the plain-English translation, and route each to the right workflow. See the denial management workflow guide.

ERA review. Medi imports 835 files and presents payment at the line level. A capped rental claim with several lines — one for KH, one for the supply item, one for a delivery charge — shows each line's allowed, paid, and adjustment amounts beside the submitted amounts. Billers flag underpayments and move them to follow-up without leaving the review surface.

Work queues. Medi scopes permissions at the practice and provider level. A billing company with several DME clients assigns billers to specific client queues without exposing another client's patient data, while operations leads see cross-client aging and denial trends from one view.

Auth tracking. Medi surfaces authorization status at the claim level. Billers attach auth numbers, see which claims are awaiting auth, and see which denied because prior authorization was rejected. Medi does not submit prior authorization requests; that stays in payer portals or the supplier's intake system.

The boundary is explicit: Medi does not generate HCPCS codes, ship capped-rental sequencing automation, perform PDAC or DMECS lookups, or capture POD documents. Those decisions stay with your billers and your clients' intake systems.

See the denial management workflow guide, the billing company software evaluation guide, or schedule a demo.

When Medi is not the right fit

Medi is not the right fit if your billing company needs DME-specific billing logic built into the platform. Capped-rental month sequencing, automated KH/KI/KJ progression, PDAC code verification lookups, and DMEPOS intake workflow management are not in Medi's feature set. If those are the core problem you need solved — especially with high-volume equipment suppliers where the rental clock and documentation capture are the bottleneck — a platform purpose-built for DMEPOS operations will serve you better.

It is also not the right fit if all your DME clients run on a single system that handles billing internally and you only provide overflow coding help rather than end-to-end billing. There, the overhead of a second platform may not justify the cross-client visibility Medi provides.

If your book is large and mixed — DME suppliers alongside physician practices — and the core problem is managing denial queues and ERA review across that book in one place, Medi fits that need.

Frequently asked questions

What is the difference between a standard written order and a written order prior to delivery?

A standard written order (SWO) is the base documentation requirement for all DMEPOS claims and must be in hand before the claim is submitted. A written order prior to delivery (WOPD) is a stricter version: the completed SWO must reach the supplier before the item is delivered. WOPD applies to specific items listed by CMS, and for those items, shipping before the written order is in hand creates a deficiency that typically cannot be corrected later. The required face-to-face encounter must precede the WOPD, which must be issued within six months of that encounter.

Do CMN forms still need to be submitted with DMEPOS claims?

No. CMS eliminated CMN (Certificate of Medical Necessity) and DIF (DME Information Form) requirements effective January 1, 2023. For dates of service on or after that date, submitting these forms causes the claim to reject. The obligation to document medical necessity remains, in the medical record and the order, but the standardized CMS forms are retired. Billers who trained before 2023 should confirm this is reflected in their submission workflow.

What happens to the capped rental billing clock when a patient changes DME suppliers?

The clock does not reset. A new supplier continues the rental sequence from the month the prior supplier stopped, not from month 1. If the prior supplier billed months 1 through 6 and the patient switches, the new supplier starts at month 7 with modifier KJ. Billers accepting transferred patients need to obtain the prior billing history to determine the correct modifier and confirm that the 13-month cap has not already been reached.

How does the DMEPOS competitive bidding program affect billing for non-contract suppliers?

Non-contract suppliers generally cannot bill Medicare for competitive bidding items in competitive bidding areas. A claim from a non-contract supplier for a CBP item in a CBP area denies because of supplier eligibility, not claim content, and that denial is not correctable by appeal or additional documentation. For billing companies managing supplier clients, knowing which clients hold CBP contracts and which product categories are in scope is a prerequisite to submitting clean claims in those areas.

What is the KX modifier and why does it matter for medical necessity?

KX signals that all requirements in the relevant medical policy are met — that the documentation on file satisfies the LCD or coverage criteria for that item. It is not a modifier to add automatically. Appending KX when the documentation does not meet the criteria is a false attestation and a compliance risk, separate from the denial risk. A claim with KX processes at the standard allowed amount when criteria are met; a claim that should carry GZ (expected denial as not reasonable and necessary, no ABN on file) is a different claim with different beneficiary liability.

Can GA, GY, and GZ modifiers be used together?

No. GA, GY, and GZ are mutually exclusive on a single claim line. Using more than one on the same line creates an unprocessable claim that must be corrected and rebilled. GA means an ABN is on file and the beneficiary was notified. GZ means no ABN exists and the supplier cannot collect from the beneficiary. GY means the item is excluded from Medicare coverage entirely. The billing situation determines which one applies — they do not stack.