Software for DME Billing Companies

Medical Billing Software for DME Billing Companies

Short answer

DMEPOS billing operates in a separate Medicare contracting system from physician and hospital claims. Four regional DME MACs — Jurisdictions A and D handled by Noridian, Jurisdictions B and C by CGS — process all fee-for-service DME claims, each with its own local coverage determinations, supplier manual, and policy articles. Claims use HCPCS Level II alphanumeric codes rather than CPT codes, and the correct code for each item is verified through the PDAC contractor's DMECS system. Modifiers carry substantial weight: KX attests that medical necessity documentation requirements are met, GA/GY/GZ govern advance beneficiary notice situations, and rental-versus-purchase modifiers (RR, NU, UE) and capped-rental progression modifiers (KH, KI, KJ) determine how the fee schedule prices each month of billing. Documentation requirements — standard written order, proof of delivery, and for many items a required face-to-face encounter — create an audit-exposure layer that physician billing does not share. 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 organizes work queues across suppliers without collapsing them. 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

Three structural differences separate DMEPOS billing from the physician and outpatient billing most revenue cycle software is built around.

The coding system is different. DMEPOS claims use HCPCS Level II codes — alphanumeric codes starting with a letter followed by four digits — rather than CPT codes. The PDAC contractor, operating through the DMECS lookup system, is the authority for which HCPCS code correctly describes a given item. For product categories where CMS has required coding verification review, a claim for a product not listed on the PDAC Product Classification List will be denied regardless of documentation quality. Billers who come from physician practices have to learn an entirely different code set, modifier stack, and fee schedule structure.

The MAC structure is different. Physician claims route to one of several Part B MACs based on provider location. DME claims route to one of four DME MACs based on the beneficiary's residence, not the supplier's location. A single supplier shipping equipment nationwide deals with all four jurisdictions. Each jurisdiction's local coverage determinations, policy articles, and supplier manual are the operative rules — not the physician MAC serving the same state. Billing companies that run multi-state DME supplier clients manage several overlapping policy environments simultaneously.

The documentation burden is different. A physician claim lives or dies on the clinical note and the order. A DMEPOS claim additionally requires a standard written order, often a required face-to-face encounter, and — for delivered equipment — a signed and dated proof of delivery record. Missing any one of those triggers a denial that has nothing to do with whether the equipment was medically appropriate. That documentation dependency makes DMEPOS billing more operationally intensive per claim than most physician billing.

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 billing Medicare must know which jurisdiction covers their patients, because LCDs, policy articles, and supplier manual chapters differ by jurisdiction even when CMS national coverage policy is the same.

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

Billing companies managing suppliers with dispersed patient populations should confirm jurisdiction routing in their clearinghouse configuration. Routing a claim to the wrong MAC is a technical denial that 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 the code set and publishes it through the HCPCS page, but product-level coding decisions are made by 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. For product categories where CMS policy 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. This is a structural compliance risk that is upstream of anything the billing company controls — but billers need to know 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 policy requires it for claim payment. The PDAC completes code verification reviews within 90 days of receiving 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 claims carry more modifier weight per line than most physician billing. The modifier 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 claim line. A line with GZ and GA simultaneously will deny as unprocessable and require correction and rebilling. Billers should know which modifier applies before the claim goes out — a supplier cannot retroactively create an ABN after the fact.

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. It must be communicated to the supplier before the claim is submitted. For many items, a written order prior to delivery (WOPD) is required — meaning a 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 elements applicable to all DMEPOS orders to reduce variation across items.

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 in subsequent years.

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 of the item sufficient to identify it (brand name, serial number, or narrative description), the quantity delivered, the date delivered, and the beneficiary or designee signature and date. The beneficiary or designee must sign to acknowledge receipt. 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) forms and DIF (DME Information Form) forms effective January 1, 2023. For services on or after that date, submitting a CMN or DIF with the claim will result in rejection. The underlying medical necessity documentation requirement remains — it lives in the medical record and the order rather than on a CMS form. Suppliers still need documentation that demonstrates medical necessity; the form itself is gone.

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 — are paid on a monthly rental basis with a hard 13-month cap on continuous use. The billing rules for capped rental items are distinct 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. For power wheelchairs, months 1–3 pay at 15% and months 4–13 at 6%. After month 13, title transfers to the beneficiary. Medicare then covers reasonable and necessary maintenance and servicing not covered under a warranty, but no further rental payments are made.

The modifier sequence for capped rental items is KH for the first month, KI for months 2–3, and KJ for months 4–13. RR is not appropriate throughout the rental period for capped rental items — it applies to other rental categories. Using 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. A new supplier picks up at the same point in the rental sequence as the prior supplier. Billing companies managing supplier clients who accept transferred patients from other suppliers 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 Medicare at the established bid price for covered items in covered areas. Non-contract suppliers are generally not paid by Medicare for competitive bidding items in CBP areas.

CMS finalized a rule in December 2025 for the next round of CBP, effective January 1, 2026, with the next round of 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 changed the reaccreditation requirement to annual rather than every three years.

For billing companies, the practical questions are: which of your supplier clients bid and won contracts, which product categories are in scope for CBP in the areas those suppliers serve, and whether the billing system can differentiate CBP claim 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.

Documentation missing before claim 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 will deny at prepayment review. The documentation gap often exists because the supplier's intake workflow is not tightly integrated with 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 actual ABN on file, GZ when GA was the correct choice, or RR on a capped rental item in month 5 — each produce different denial codes and require different corrective action. Billing companies need to see which modifier generated the denial, not just that the line denied.

Medical necessity denials under KX criteria mean the supplier billed the KX modifier but the documentation on file does not actually satisfy the LCD's requirements. This is a compliance exposure as well as a denial — the claim was attested as meeting criteria when it did not.

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

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

Competitive bidding noncompliance, when a non-contract supplier bills for a CBP item in a CBP area, produces a denial that is not correctable by appeal. 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. It does not auto-code HCPCS Level II, it does not generate documentation, and it does not 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.

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

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

For work queues, Medi supports practice-level and provider-level permission scoping. A billing company with several DME supplier 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 a single view.

For auth tracking, Medi surfaces authorization status at the claim level. Billers attach auth numbers, see which claims are awaiting auth, and see which moved to denial because the prior authorization was rejected. Medi does not submit prior authorization requests to payer portals — that still happens through payer portals or the supplier's intake system.

What Medi does not do in DME workflows: it does not generate HCPCS codes, does not ship capped-rental billing logic or rental-month sequencing automation, does not perform PDAC or DMECS lookups, and does not manage POD document capture. Those decisions and workflows stay with your billers and your supplier 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 intake workflow management are not in Medi's feature set. If those workflows are the core problem your billing company needs solved — particularly if you serve high-volume equipment suppliers where the rental-billing clock and documentation capture are the operational bottleneck — a platform purpose-built for DMEPOS operations will serve you better.

Medi is also not the right fit if all your DME supplier clients run on a single software system that handles billing internally and you are only providing overflow coding help rather than end-to-end billing. In that scenario the per-client overhead of a second platform may not justify the cross-client visibility Medi provides.

If your book is large and diverse — DME suppliers alongside physician practices — and the core problem is managing denial queues and ERA review across that mixed 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 — it must be in hand before the claim is submitted. A written order prior to delivery (WOPD) is a stricter version of the same requirement: a completed SWO must reach the supplier before the item is delivered to the beneficiary. WOPD applies to specific items listed by CMS, and for those items, shipping equipment before the written order is in hand creates a documentation deficiency that typically cannot be corrected after the fact. The required face-to-face encounter must precede the WOPD, and the WOPD 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 with a claim causes the claim to be rejected. The underlying obligation to document medical necessity remains — it belongs 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 is a modifier a supplier appends to signal that all requirements specified in the relevant medical policy have been met — meaning 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 actually 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 if coverage criteria are met; a claim that should carry GZ (expected to be denied as not reasonable and necessary, no ABN on file) is a different claim with different beneficiary financial liability implications.

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.