Payment Links and Plans for OB-GYN Practices

Payment links and plans matter more in obstetrics than in almost any other specialty, for a structural reason most billing advice ignores. The patient is in a relationship with your practice for roughly nine months before the bill that matters arrives, and the balance she owes is decided by a deductible year that will probably tick over somewhere in the middle of it.

Global maternity billing bundles prenatal visits, delivery, and postpartum care into one charge that goes out after delivery. Everything before that point is care your practice has already provided and not yet billed. The patient sees a long stretch of appointments with no invoice, forms an impression that this is covered, and then receives a bill for a four-figure balance in the same month she has a newborn. Every part of that sequence is normal, correct billing, and it produces the hardest collections conversation in the practice.

The balance is knowable long before it is billed

The useful thing about global maternity is that it is predictable. The patient’s plan, her remaining deductible, her coinsurance, and the practice’s contracted rate are all knowable at the first prenatal visit, which is months before anyone asks her for money.

Most practices do not use that window. Verification runs at intake, the estimate is either not produced or produced once and filed, and the next financial conversation happens after delivery. The patient is asked to absorb a number she has never seen, at the point in her life when she has least attention available for it.

Running the estimate early and putting it in front of the patient converts the entire pregnancy into a collection window. That is the whole strategy. It is not a payment technology problem; it is a timing problem that payment technology makes solvable, because a link that arrives in month three has eight months of pay periods behind it and a link that arrives in month ten has none.

The deductible resets in the middle of the pregnancy

This is the complication that breaks maternity estimates, and it catches practices every January.

A patient who conceives in spring will have prenatal care in one benefit year and deliver in the next. The deductible she has already met does not carry over. An estimate produced at the first visit and never revisited will be materially wrong by delivery, and wrong in the direction that surprises the patient, because the delivery charge lands against a fresh, unmet deductible.

The fix is mechanical: re-verify eligibility at the benefit year boundary for every active maternity patient, regenerate the estimate, and tell the patient before she finds out from the bill. That is a batch job with a date attached, and it is exactly the kind of work that does not get done when it depends on a person remembering in the first week of January.

A payment plan set up in the previous year needs the same treatment. If the plan was sized against the old estimate, it under-collects, and the practice discovers this after delivery when the remaining balance is larger than the plan was built for. Re-sizing the plan at the boundary, with the patient’s agreement, is a conversation that goes fine in November and badly in March.

What the plan has to know before it offers terms

A payment plan that the practice has to police is worse than no plan, so the terms have to come from rules rather than from whoever is at the desk.

The automation needs the practice’s own policy: the minimum monthly amount it will accept, the longest term it will allow, whether plans can extend past delivery, and what happens when a payment fails. It also needs to know which patients are not eligible for a self-service plan at all, usually because a prior balance is already in collections or because the account carries a financial assistance determination that a payment plan would override.

With that in place the offer becomes deterministic. The patient gets a link, sees the estimated responsibility, picks from terms the practice actually permits, and the plan is recorded against the account without anyone negotiating.

For a worked example, assume an estimated patient responsibility of $2,400 identified at a first prenatal visit in month two, with delivery expected in month eleven. Nine monthly installments of about $267 collect the full balance before the global charge is even submitted. That is a worked example, not measured benchmarks. Your contracted rates and your own policy limits will change every figure in it.

The point of the arithmetic is not the number. It is that the same balance, approached after delivery, becomes a single large invoice to a household that just added a dependent, which is the version that ends up in a payment plan anyway, only involuntarily and after three phone calls.

The link has to arrive where the patient already is

Payment links fail for boring reasons, and most of them are about delivery rather than about payment.

A link buried in a portal message competes with portal messages. A link in a paper statement arrives two weeks after the charge and requires the patient to type a URL. The links that get used arrive by text, reference something the patient recognizes, and open to an amount that matches what she was told to expect. When the amount on the link does not match the estimate she was given, she calls, and the practice has spent a text message to generate a phone call.

The automation should send the link at the moments that already exist in the workflow: after the estimate is generated, after each visit that adds a charge outside the global package, at the benefit year boundary when the plan is re-sized, and on the plan’s own schedule. It should also stop. A balance that has been paid, disputed, or moved to financial assistance should drop out of the outbound sequence immediately, and the most common complaint about automated collections is that it did not.

When a patient replies with a question rather than a payment, that goes to a person. Billing questions in obstetrics are frequently not billing questions.

The denial arrives after the baby does

The other half of maternity revenue protection is that the claim itself is at unusual risk, and the risk is administrative rather than clinical.

Across ACA marketplace plans with complete data, KFF found nearly 19% of in-network claims were denied in 2024, with about 9% of denials attributed to lack of preauthorization or referral. In a global maternity claim the exposure is concentrated: one submission covers nine months of care, so a denial for a missing authorization or an eligibility problem puts the entire episode in appeal rather than a single visit.

That is an argument for doing verification more than once. An eligibility check at intake tells you about a plan the patient may no longer have by delivery, and coverage changes during pregnancy are common because pregnancy is a qualifying life event. Re-verifying at the benefit year boundary and again in the weeks before delivery costs almost nothing when it is automated and prevents the version of this where the practice discovers a coverage change after submitting the global charge.

When the automation finds a mismatch, the useful behavior is to flag it to the billing team with the specific difference stated, rather than to attempt a correction. Coverage changes usually need a human to call the patient, and that call is much easier before delivery than after.

Where the automation hands off

Collections in obstetrics touches patients at a sensitive moment, and the boundary should be drawn generously rather than narrowly.

The automation produces the estimate, offers plan terms the practice authorized, sends the links, records the payments, re-verifies coverage on schedule, and reports exceptions. It does not decide who deserves financial assistance, it does not negotiate, and it does not pursue an account that a patient has disputed.

It should also recognize a set of conditions where outbound collection activity stops entirely and the account routes to a person. A pregnancy loss is the obvious one, and it is the case that makes practices nervous about automating this at all. The answer is a hard stop rule: when the practice flags an account, every automated financial message on it ends immediately, and no sequence restarts it. That rule is worth writing and testing before the first link goes out.

Handled that way, what the practice has automated is the arithmetic and the reminders, which is the part that was being done inconsistently, and kept the judgment, which is the part that should never have been on the schedule anyway.

Key Takeaways

Produce the maternity estimate at the first prenatal visit, not after delivery. The pregnancy is the collection window, and a payment link sent in month three has eight months of pay periods behind it.
Re-verify eligibility and regenerate estimates at the benefit year boundary. A patient who conceives in spring delivers against a deductible that reset, and an estimate from the first visit will be wrong by delivery.
Re-size payment plans at that same boundary. A plan built on the old estimate under-collects, and you find out after the global charge goes out.
Encode the plan terms your practice actually permits, including who is ineligible. A plan the billing team has to police costs more than it collects.
Send links by text at the moments already in the workflow, and make the sequence stop instantly when a balance is paid, disputed, or moved to assistance.
Write the hard-stop rule for pregnancy loss before launching anything. One flagged account should end every automated financial message on it, permanently.

Global maternity billing concentrates nine months of care into a single claim and a single patient balance, which makes it both the largest collections risk in an OB-GYN practice and the most predictable one. Nothing about improving it requires a judgment call. It requires the estimate to exist early, the eligibility check to run more than once, the plan terms to be the practice’s own, and the outbound sequence to stop when it should. That is a good description of work worth handing to an AI team operating inside athenaOne.

Sources