An installed OAuth app can also subscribe to these events in its provider's account.
Event payloads
Stedi events use a thin event schema. A thin event notifies you that a resource changed, but it doesn't include the resource's data.
A single file with multiple transactions produces one file.processed event and one transaction.processed event per transaction. The relatedResources array identifies the transaction type.
You can now find a patient's insurance coverage and benefits in one click using Agentic Discovery.
Agentic Discovery combines eligibility checks, automated check recovery, and insurance discovery into a single, automated workflow.
With Agentic Discovery, you start by entering the data you have about a patient, such as name, date of birth, and – if you know it – the payer ID. The agent runs an eligibility check. If the check succeeds, the agent stops. If the check fails, the agent tries to recover it using Stedi's best practices. For example, the agent may try follow-up eligibility checks with variations of the patient's name.
If recovery fails, the agent then runs an insurance discovery check. Insurance discovery checks can find coverage based on limited information, even if the original eligibility check had missing or incorrect information.
Previously, you had to manually sequence and run each of these steps separately.
Agentic Discovery is now the default way to run eligibility checks in the Stedi portal. It also replaces the previous iteration of eligibility check recovery in the Stedi Agent. The Resolve with Stedi Agent option is still there, but it now runs the more complete Agentic Discovery check instead.
Watch the 2026 Stedi Keynote announcement:
How to run an Agentic Discovery check
You can start an Agentic Discovery check from the Stedi portal in three ways:
Click + New eligibility check on a failed eligibility check in the checks view.
Select Agentic Discovery on the Stedi Agent's Chats page.
Click Launch Agentic Discovery for failed eligibility checks in the checks view.
Each option opens a form in the Stedi Agent. To run an Agentic Discovery check, enter or change the patient, provider, and payer details, then click Submit.
To run a manual eligibility check without Agentic Discovery, click Use the standard eligibility check form instead.
What data do I need to run an Agentic Discovery check?
You only need to provide:
The patient's first name
The patient's last name
The patient's date of birth, member ID, or Social Security Number (SSN)
The provider's NPI
We recommend you include as much information as you have, such as the state of the patient's address. Additional information increases the chances of finding active coverage.
If you don't provide a date of service, the check defaults to today's date. If you don't provide a Service Type Code (STC), the check defaults to 30 (Health Benefit Plan Coverage).
If you don't provide a payer, the agent runs an insurance discovery check using the patient's information.
Agentic Discovery is available for all Stedi production accounts.
Agentic Discovery checks are priced per agent run. You won't be billed separately for underlying eligibility or insurance discovery checks the agent uses. For pricing, see our Pricing page.
Agentic Discovery isn't available in test mode or sandbox accounts. In test mode, use the standard eligibility check form to run mock eligibility checks.
You can now track a claim's full lifecycle – from submission to payer adjudication – in the Stedi portal's claims view. For example, you can see whether the payer denied a claim, or how much the payer paid.
Processed by payer – The payer completed adjudication and accepted responsibility for the claim. This doesn't mean the payer paid the claim in full, or paid it at all.
Denied – The payer completed adjudication and denied responsibility for the claim.
Unknown – Stedi can't determine a single status for the claim. This usually happens when the payer's responses are mixed or incomplete.
The Unknown status replaces the old Invalid status, which only applied to 277CA claim acknowledgments with unrecognized status codes.
The Submitted, Received, Rejected, and Accepted statuses remain unchanged. For more, see How we determine status in our docs.
Claim timeline
Each claim's timeline now includes a card for every claim payment information record from an ERA. Each card shows the claim processing status, the amount charged, the patient responsibility, the amount paid, and the ERA trace number.
Resubmissions carry their own payment records, so you see the payments tied to each attempt.
Claim payment information details
Hover over a claim payment information card and click See more detail to open its details. That view shows payment information for one claim:
The linked claim, with a link back to its timeline.
Claim-level payment information: total charged, total paid, patient responsibility, and adjustments. If the claim was denied, denial reasons are also included.
Service line details, with line-level payment amounts and adjustments.
You can view the CLP (Claim Payment Information) segment of Loop 2100 for the related ERA in the X12 tab. You can also download a PDF for a single claim payment information record.
ERA detail view
Each ERA detail view has a claim payment information table with one row per claim payment information record. Click a row to open the details for that claim.
If you receive ERAs through Stedi but submit claims elsewhere, you still get the claim payment information details for each record in an ERA.
Availability and pricing
Claim lifecycle tracking is available now in the Stedi portal's claims view for all Stedi production accounts at no extra cost.
Stedi apps are pre-configured integrations between a provider's Stedi account and an external platform, like an electronic health record (EHR), practice management system, or revenue cycle management (RCM) system.
We're releasing a completely revamped, OAuth-based version of Stedi apps that allows deeper, more seamless integration with external applications. OAuth Stedi apps include several new features:
One-click installation – Providers can install a Stedi app without copying API keys or SFTP credentials between Stedi and the app.
Support sessions – App developers can open a time-limited support session in a provider's Stedi account.
Self-provisioning – An installed Stedi app can create its own event destinations and SFTP users, run eligibility checks, and manage transaction enrollments in a provider's Stedi account.
Self-service app registration – App developers can create an app and get OAuth credentials directly in the Stedi portal.
Redesigned Stedi app store – App developers can list their app so providers can find and install it.
Previously, providers had to generate API keys and SFTP credentials and share them with the app developer. To provide support, the app developer's staff had to join the provider's Stedi account as members. That access lasted until the provider removed the members.
Now, industry-standard OAuth replaces that credential handoff. A provider installs an app by approving one consent screen. The app developer's support staff can work in a provider's Stedi account through a time-limited session instead of a standing login.
Important: We're not changing existing Stedi apps that use API keys or SFTP credentials as part of this release. All existing Stedi apps will continue working. If you're a current Stedi app developer who wants to upgrade to OAuth, contact us.
Watch the 2026 Stedi Keynote announcement:
One-click installation for providers
A provider can click an install link in the app developer's platform, or select the Stedi app in the redesigned Stedi app store. Stedi then shows a consent screen with the app's name and the exact permissions the app requests.
The provider approves, and the connection is live.
Support sessions
App installation grants the app developer the ability to run a time-limited support session in the provider's account. When a provider uninstalls the app, that ability is removed. Support sessions use the app's permissions – nothing more.
Self-provisioning
Once the provider approves the app, the app can set up the account itself. It calls Stedi APIs with its own tokens.
An app can create event destinations, create SFTP users, run eligibility checks, and manage transaction enrollments. It acts under the exact permissions the provider approved on the consent screen. Stedi labels each resource the app creates, so providers can see what the app manages.
Stedi also sends app.installed and app.uninstalled events to the app developer's own Stedi account. Providers can uninstall an app at any time, and its access ends within an hour.
Self-service for app developers
App developers can now register apps in the Stedi portal and get their OAuth credentials there. The entire process is self-service.
App developers can list their app in the redesigned Stedi app store so providers can find it. Each Stedi account can have one active app installed.
Pricing and availability
It's free to build and publish a Stedi app. There are no developer fees. It's also free for providers to install an app.
OAuth Stedi apps are in private preview. We're onboarding new Stedi app developers. Contact us if you want to build a Stedi app.
The new endpoint's response format makes it easier to parse a patient's benefits.
The legacy JSON Real-Time Eligibility Check API endpoint returns responses in a structure that mirrors the X12 eligibility response. Benefits for different plans and different benefit types are intermixed in a flat benefitsInformation array. The array is "polymorphic": the fields in each entry change depending on the benefit type. The responses also use X12 codes, like C for a deductible or F for limitations, so you map each one to its meaning.
The new endpoint removes the polymorphism. It groups benefits by health plan. In each plan, it breaks the payer's benefit details out into separate typed objects: statuses (for example: ACTIVE_COVERAGE and INACTIVE), coPayment, coInsurance, deductible, and more. It spells values out: ACTIVE_COVERAGE instead of 1, IN_NETWORK instead of Y. Each benefit names the Service Type Code (STC) or procedure code it applies to.
To run checks with the new endpoint, you only need to provide the same information you use to run eligibility checks today: the payer ID, the provider's name and NPI, the patient's details, and the STC or procedure code you want benefits for.
Providers can now receive payer paper checks, paper remits, and other mail items at a lockbox address managed by Stedi. A lockbox is a secure mailing address that receives mail on the provider's behalf. The provider can give the address to payers that require a mailing address for physical mail. Stedi deposits any checks received into a Stedi Treasury account automatically. Stedi scans the remits and other mail into PDFs you can view and download.
Checks become payment records in the Stedi portal. Paper remits and other mail become PDFs with OCR text that can be used for downstream processing.
Watch the 2026 Stedi Keynote announcement:
Automatic check deposits
Electronic Funds Transfers (EFTs) are the standard option for payer payments, but payers don't always pay electronically. Many still mail paper checks, and many mail paper remits – explanations of payment (EOPs) or explanations of benefits (EOBs) – instead of Electronic Remittance Advice (ERAs).
All that paper turns into manual work for the provider. Someone has to open the envelopes, match each check to its remit, and deposit the checks by hand.
Stedi Lockbox takes that work off the provider. Stedi receives the mail, scans it, and deposits any check into the associated Stedi Treasury account.
These check deposits appear in the Stedi portal the same way EFTs do, with one addition – a Mail card showing that the payment arrived as a paper check.
The related payment's detail page includes a scanned image of the check.
Paper remits and other mail
When a lockbox receives a paper remit, such as an EOP or EOB, Stedi makes it available in the related Stedi account as a PDF. Each PDF includes optical character recognition (OCR) text, so you can process the contents downstream.
The same applies to every other item of mail. You get the PDF, the OCR text, and the sender, then decide what to do next.
Availability and pricing
Stedi Lockbox is in private preview for Stedi production accounts. Reach out if you're interested in joining the preview.
You can now enroll for EFTs, then receive and automatically reconcile payments from payers with Stedi Treasury.
Stedi Treasury unlocks simple EFT enrollment along with automatic reconciliation. You can enroll for EFTs and track the entire claim lifecycle from claim submission to payout in the Stedi portal.
Previously, providers had to navigate a confusing variety of payer-specific processes to enroll for EFTs. Reconciling each payment to the corresponding ERA and related claims took a series of manual steps.
Watch the 2026 Stedi Keynote announcement:
How Stedi Treasury works
When a provider signs up for Stedi Treasury, we provision a demand deposit (DDA) bank account in the provider's name via our banking partner, Grasshopper Bank. Treasury accounts are in the provider's name, FDIC-insured up to $250,000, and are fully integrated with your Stedi account for payment tracking and reconciliation. Each Treasury account takes about five minutes to set up.
With Treasury, you submit and track EFT enrollments with the same transaction enrollment process you already use for ERAs, either using the Stedi portal, CSV, or API. Where possible, Stedi handles the paperwork for you, including generating voided checks and verification letters, and verifying micro-deposits.
Once the enrollment process is complete, payments from payers land in the provider's Stedi Treasury account. Stedi then automatically pays out the full amount to the provider's external bank account as a next-day ACH payment. Stedi doesn't delay or batch the funds.
Setup for Stedi Treasury takes three steps:
Create one or more billing entities for the provider.
Link each billing entity to an external bank account.
Enroll the provider for EFTs through Stedi with each payer.
Stedi supports over 750 payers for EFT enrollment, with more being added every day. Check the Payers API or the Stedi Payer Network to confirm that a payer supports EFT and to check their enrollment requirements.
Payments and payouts
The Payments page lists funds a payer sends to a Treasury account. A payment is Pending while the funds settle, then Received.
The Payouts page lists payouts – ACH deposits from a Stedi Treasury account to the linked external bank account. Each payout lists its current status, moving from Pending to In transit to Paid.
Each payment gets its own payout for easier tracking. If a Stedi Treasury account receives a $100 payment, Stedi issues a $100 payout. Payouts aren't bundled. Any fees are billed separately.
You can also access monthly bank statements showing all credits and debits to the billing entity's Stedi Treasury account.
Automatic reconciliation
If you submit claims and receive ERAs through Stedi, you can trace an individual payment on the payment's detail page back to its ERA and claim in the Stedi portal's claims view.
Stedi associates payments with ERAs based on the reassociation trace number returned in both.
Stedi Lockbox
A Stedi Lockbox is a mailing address that receives payer mail on the provider's behalf. When you sign up for Stedi Lockbox, you get one. You can give the address to payers whenever they require a mailbox for paper remits.
When a Stedi Lockbox receives a paper check, it's automatically scanned and deposited into the associated Stedi Treasury account. These check deposits appear in the Stedi portal the same way EFTs do, with one addition – a Mail card showing that the payment arrived as a paper check.
When a Stedi Lockbox receives a paper remit, such as an EOP or EOB, Stedi makes it available in the related Stedi account as a PDF. Each PDF includes optical character recognition (OCR) text, so you can process the contents downstream.
Availability and pricing
Stedi Treasury is generally available in the Stedi portal for Stedi production accounts. API access is coming soon. Contact us to turn it on for your account.
Stedi Treasury is priced as a percentage of gross payment volume. Fees are billed separately from payouts. See our pricing page for rates.
Stedi Lockbox is in private preview for Stedi production accounts. Reach out if you're interested in joining the preview.
Stedi is a financial technology company, not a bank. Banking services are provided by Grasshopper Bank, N.A., Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.
You can now test the entire claims workflow using test mode, including Stedi test API keys and test SFTP credentials. You can simulate a claim's lifecycle from end to end without submitting a real claim to a payer.
Previously, you could only submit test claims in production and had to mark each claim as a test. You couldn't include claim attachments for test claims.
We're deprecating the ability to submit test claims in production. New Stedi accounts can only submit test claims using a Stedi test API key, test SFTP credentials, or test mode in the Stedi portal.
If you already submit test claims in production, your current workflows will continue working. We recommend switching to test mode for test claim submissions. This ensures a mistyped usageIndicator or ISA15 can't send a live claim to a real payer.
For more information on submitting test claims, see Test claim workflows in our docs.
Claim acknowledgments and ERAs for test claims
The payer you send a test claim to determines which test responses, such as 277CA claim acknowledgments or test ERAs, you get back. It also determines which claim edits Stedi uses to validate the claim.
You can now use Stedi's Claims Lifecycle API endpoints to retrieve the same claim records that power the claims view in the Stedi portal. The endpoints return the claim's status, submission date, charge amounts, paid amounts, and full history, providing a powerful headless RCM engine that can drive external applications.
Previously, the Stedi portal's claims view was the only place to see a claim's full lifecycle. Through the API, you received each response on its own – a 277CA claim acknowledgment here, an ERA there. You had to match each response back to the original claim, usually on the patient control number (PCN).
Now Stedi does the matching and returns the result. The new endpoints serve the same claim data that powers the claims view, so your dashboard can show what the portal shows.
Watch the 2026 Stedi Keynote announcement:
Claim records
A claim record holds summary information about a claim, including its current status. A Retrieve Claim API response contains a single claim record:
{ "id": "clm_01K6XFP3TZ8RA9X84963NMW40N", // Stedi's claim ID "patientControlNumber": "123456", "patientName": { "firstName": "John", "lastName": "Doe" }, "type": "PROFESSIONAL", "stediPayerId": "ABCDE", "datesOfService": { "start": "2026-01-05" }, "submittedAt": "2026-01-16T10:00:00Z", // Time Stedi processed the most recent submission "status": "PROCESSED", "statusReportedBy": "PAYER", // PAYER or CLEARINGHOUSE "totalClaimChargeAmount": "832.00", "totalClaimPaidAmount": "200.00" // Sum of payments matched to the claim from ERAs. Includes reversals (negative amounts)}
The claim record's status field uses the same claim processing statuses as the portal: SUBMITTED, RECEIVED, ACCEPTED, REJECTED, PROCESSED, DENIED, and UNKNOWN.
Claim IDs
Each claim record includes a claim ID. The ID stays the same for the life of the claim. A resubmission updates the record, but doesn't change the claim ID. One claim ID tracks the claim across every submission.
Filters and pagination
You can use the List Claims API endpoint to filter a list of claim records by status, patientControlNumbers (up to 20), and a submittedAfter/submittedBefore time range.
For example, this request returns denied claims submitted since January 1:
curl --request GET \ --url "https://claims.us.stedi.com/2025-03-07/claims?status=DENIED&submittedAfter=2026-01-01T00:00:00Z" \ --header 'Authorization: <api-key>'
You can page through responses using token-based pagination. Responses include a nextPageToken when more results are available. The pageSize parameter defaults to 100 claim records, up to a maximum of 500.
Claim timeline
The Retrieve Claim Timeline API endpoint returns one entry per event in the claim's history, newest first. Each entry holds exactly one property, and the property name tells you the entry type:
professionalClaimSubmission, institutionalClaimSubmission, or dentalClaimSubmission – A submission or resubmission.
claimAcknowledgment – A 277CA claim acknowledgment from Stedi or the payer.
claimPaymentInformation – A claim payment information record from an ERA.
A resubmitted claim carries every attempt on one timeline, along with the acknowledgments and payments tied to each attempt.
Validates the claim using Stedi's database of claim edits without sending the claim to the payer. Returns an empty 200 response if the claim passes Stedi's edits, or an error if it doesn't.
Returns a submitted claim in the CMS-1500 JSON structure. You can then make corrections to the claim and resubmit it using the CMS-1500 Create Professional Claim Submission endpoint.
The CMS-1500 – also called the HCFA form – is the standard paper form for professional claims. Every box on the form has a number. Many billers know these numbers. Payers cite them in their own guides. And many AI agents are trained on them.
Now developers and AI agents can apply what they know about the CMS-1500 to Stedi's API. The new endpoints are the same ones that power Stedi's own claim form.
Important: We're not deprecating the JSON 837P Professional Claim Submission endpoint or any other functionality as part of this release. Your existing integrations will continue working.
Watch the 2026 Stedi Keynote announcement:
Request shapes
The new endpoints group fields the same way the CMS-1500 form does. The API reference includes the box number for most fields.
For example, Box 24 – Service lines of the CMS-1500 form is the grid where you list each service you bill. One row of that grid is one object in the serviceLines array.
Test mode support
You can use the CMS-1500 Create Professional Claim Submission and CMS-1500 Retrieve Professional Claim Submission endpoints in test mode. You need a test API key for a Stedi production account.
The CMS-1500 endpoints are available on all Stedi production accounts.
Claim retrieval is free. Test claim submissions are free. Production claim submissions and validations are priced per transaction. For pricing, see our Pricing page.
We're releasing official software development kits (SDKs) for TypeScript and Python. The SDK packages are available from npm and PyPI.
Previously, Stedi only offered REST APIs. If you wanted language-specific types, retries, or error handling, you had to write your own client. Every customer who integrated with Stedi had to repeat that work.
Now the SDKs do that work for you. You get types, retries, and error handling as part of the SDKs. You only need to write the parts that are specific to your product.
This initial SDK release includes operations covering the following API endpoints:
When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.
Track a paper claim's print status in the Stedi portal's claims view.
View a PDF proof of the printed claim package in the Stedi portal.
With paper claims, Stedi prints and mails the claim to any payer for you. You submit them through the same Stedi APIs, SFTP, and Stedi portal UIs you use for electronic claims.
Previously, paper claims covered only professional (CMS-1500) and institutional (UB-04) claims. Attachments weren't supported. You got one 277CA claim acknowledgment when Stedi forwarded the claim for printing. Nothing told you whether the claim reached the mail.
Watch the 2026 Stedi Keynote announcement:
Submit dental paper claims
You can now submit dental claims as paper claims using the following methods:
Stedi pairs the claim with the attachment, prints both, and mails them to the payer together.
Track paper claims
The Stedi portal's claims view now follows each paper claim through print and mail. The claim's timeline adds a row for each print stage, newest first.
Print status
What it means
Staged
Stedi accepted the claim for mailing.
Queued
Stedi's print-and-mail partner queued the claim for printing.
Printed
The partner printed the claim form and any attachments.
Mailed
The partner mailed the claim package to the payer.
Failed
The claim wasn't mailed. The timeline row shows the reason.
The claims list shows the same status as an icon in the Status column. You can also filter the list by print status.
The payer address failed validation, so Stedi didn't mail the claim.
The earlier print stages don't produce a 277CA. You track those in the claims view.
Download PDF proofs
Every printed paper claim now has a PDF of the claim package, including the printed form and any attachment pages. The Printed row in the claim's timeline holds the file.
Availability and pricing
Paper claims are available on all Stedi production accounts.
Stedi charges for paper claims per page printed and mailed. The page count depends on the claim type, its service line count, and any attachments.
Claim type
Service lines per page
Professional claim (CMS-1500 form)
Up to 6
Institutional claim (UB-04 form)
Up to 22
Dental claim (ADA dental claim form)
Up to 10
A claim spills onto additional pages when its service lines exceed what one form holds. Attachment pages count the same way.
On October 1, 2015, the U.S. healthcare system replaced ICD-9 with ICD-10. Both the diagnosis code sets and the inpatient procedure code sets changed on that date. A payer won't accept a claim that declares ICD-9 for a service on or after that date.
A claim declares its code set with a code list qualifier. The qualifier sits in a Health Care Code Information (HI) segment in Loop 2300, and it introduces the code that follows it. Each HI segment holds up to 12 composites, so a qualifier can also appear in HI02-1 through HI12-1.
Clinical Modification (CM) diagnosis qualifiers in 837P professional claims
HI01-1 (Code List Qualifier Code) of the Other Procedure Information HI segment in Loop 2300
The edit compares the qualifier against a governing date. A date of injury governs when the claim carries one. ICD-9 stays valid for an injury that predates the transition, even when the services came later. Otherwise each service line's own date of service governs.
HI segment in Loop 2300 (Occurrence Information) with qualifier BH
A service date is required on every 837P service line. On an 837I claim it's optional, so the edit falls back to the claim statement date in claimInformation.claimDateInformation.statementEndDate (DTP-03 of Loop 2300 with qualifier 434).
How the edit works
If a claim uses an ICD-9 qualifier and a governing date falls on or after October 1, 2015, the payer may reject the claim.
837D dental claims don't carry ICD-9 qualifiers, so this edit doesn't apply to them.
This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.
Rejection errors
If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:
{ "errors": [ { "code": "33", "description": "Invalid ICD-9 Qualifier usage. A code list qualifier indicating ICD-9 can not be used for service dates after 09-30-2015. Submitted qualifier(s): BK. Correct and resubmit.", "followupAction": "Please Correct and Resubmit" } ]}
The error names every distinct ICD-9 qualifier on the claim.
STC*A7>508*[DATE]*U*[AMOUNT]******A7>488**Invalid ICD-9 Qualifier usage. A code list qualifier indicating ICD-9 can not be used for service dates after 09-30-2015. Submitted qualifier(s): BK. Correct and resubmit.~
Resolution tips
This edit checks the qualifier. It doesn't check the code the qualifier introduces. To resolve a rejection, change the qualifier to its ICD-10 counterpart, change the code to an ICD-10 code, or change both.
Previously, you had to use the Stedi portal to manage event destinations or rotate signing secrets. Now, you can also do both programmatically from an application or script.
If you're a Stedi app developer, you can use these API endpoints to configure event destinations for your providers' accounts.
The new endpoints are available for free on all Stedi production accounts. For more details, see our announcement blog.
In a claim, each entity, such as the billing provider or submitter, is identified as either a person or a non-person using an entity type qualifier. Non-person entities include hospitals, billing organizations, and similar groups.
X12 standards require the organization name when an entity is a non-person. In X12, this is the entity's NM1-03 element. If the organization name is missing, the payer may reject the claim.
This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.
If you use X12, you set the entity type qualifier in NM1-02 (Entity Type Qualifier). 1 indicates a person and 2 indicates a non-person entity, such as a hospital or billing organization.
Rejection errors
If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:
{ "errors": [ { "code": "33", "description": "Missing Organizational Name. The organizational name is required when Billing Provider is reported as a non-person by the entity type qualifier 2. Correct and resubmit.", "followupAction": "Please Correct and Resubmit" } ]}
STC*A6>125>85*[DATE]*U*[AMOUNT]********Missing Organizational Name. The organizational name is required when Billing Provider is reported as a non-person by the entity type qualifier 2. Correct and resubmit.~
CLM01 (Patient Control Number) of Loop 2300 (Claim Information)
How the edit works
X12 standards require a PCN on every claim. If you submit a claim without a PCN, the payer may reject the claim.
This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.
Rejection errors
If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:
{ "errors": [ { "code": "33", "description": "Missing Patient Control Number. A patient control number is required and must be 20 characters or fewer. Correct and resubmit.", "followupAction": "Please Correct and Resubmit" } ]}
STC*A6>481*[DATE]*U*[AMOUNT]********Missing Patient Control Number. A patient control number is required and must be 20 characters or fewer. Correct and resubmit.~
You can now review 999 Implementation Acknowledgments in a new Overview tab on the Stedi portal's Transactions page. The tab shows which transaction sets Stedi accepted, which it rejected, and why, in a human-readable format.
Previously, with only X12 and JSON tabs, you had to locate the AK9 and IK5 segments yourself and look up each error code in the implementation guide.
The Overview tab shows:
The functional group's identifier, control number, and acknowledgment code, plus how many transaction sets Stedi received and how many it accepted.
A section for each transaction set, with its control number and acknowledgment code.
For each rejected transaction set, a table of errors listing the X12 address, the error code, and the value that failed validation.
A 999 confirms X12 syntax only. To verify whether the payer accepted your claim, check the 277CA claim acknowledgment.
Stedi now rejects 837I institutional claims with a service line date outside the claim's statement covers period.
Statement covers periods and service dates
An institutional claim can bill for a range of dates. This range is called the statement covers period. You report the statement covers period at the claim level.
DTP*434 (Statement Dates) of Loop 2300 (Claim Information)
Service lines can also carry their own service dates. X12 standards require service dates on outpatient service lines when the statement covers period is longer than one day.
DTP*472 (Service Date) of Loop 2400 (Service Line)
How the edit works
Each service date on a claim must fall within the statement covers period. If you include a service date outside the statement covers period, the payer may reject the claim.
This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.
Rejection errors
If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:
{ "errors": [ { "code": "33", "description": "Invalid Service Date. The service date must fall within the claim's statement dates. The service date, 20241020-20241020, on line 1 falls outside the claim's statement dates of 20241015-20241017. Correct and resubmit.", "followupAction": "Please Correct and Resubmit" } ]}
STC*A7>187**U*******A8>188**Invalid Service Date. The service date must fall within the claim's statement dates. The service date, 20241020-20241020, on line 1 falls outside the claim's statement dates of 20241015-20241017. Correct and resubmit.~
Resolution tips
You have two ways to fix the claim:
Widen the statement covers period. Change the begin or end date so it includes the service date.
Split the claim. Move the service line to its own claim, with a statement covers period that includes the service date.
Related claim edits
Stedi has another edit for date ranges that start after they end. See Invalid date range.
If a patient's care is covered by more than one payer, a payer may forward the claim to the next payer after adjudication. These are called crossover claims. The payer that receives the forwarded claim is the crossover carrier.
Previously, the PDF status line only stated Forwarded to Additional Payer(s) when a claim was forwarded. To find the crossover carrier, you often had to check the underlying ERA or the payer's portal. Now, ERA PDFs show the name in these cases:
You can now sign up for a production Stedi account for as little as $25.
Stedi's pay-as-you-go plan now only requires a starting balance of $25. Stedi adds $25 to your balance whenever it drops below $10.
Previously, signing up required a $100 starting balance, and Stedi added $100 whenever your balance dropped below $25.
Per-transaction rates stay the same. Each transaction uses your balance at the rate set by its pricing tier. To estimate costs or see all tiers, check our pricing page.
