The PYE segment was introduced in HL7 v2.7 as part of the financial-management chapter to identify the party that should receive funds for a given financial transaction. It distinguishes the payee — the person, organization, or institution paid — from the guarantor (GT1), the patient (PID), and the insurance subscriber (IN1/IN2), all of which can be different entities in real-world payment flows.
This page documents the segment as it appears in HL7 v2.8.1.
Purpose
PYE answers a single question: who gets the money. That sounds redundant in simple settings where the provider organization is always paid, but it becomes essential when:
- A patient is reimbursed directly by an insurer after paying out-of-pocket.
- A third-party billing service or factoring agent receives provider payments.
- A guardian or estate is paid on behalf of a deceased or incompetent patient.
- A court-ordered assignment redirects payments to a specific recipient.
PYE carries the payee's type (PYE-2), identification numbers (PYE-4), name (PYE-5), address (PYE-6), and the method by which they are paid (PYE-7).
Used in
PYE is part of the financial transaction message family and appears in the DFT message (Detailed Financial Transaction) when the payee differs from the default billing party. It is also valid in BAR (billing-account) messages where account-level payee defaults are being established or updated.
Field-by-field reference
Source: HAPI HL7v2 v2.8.1 javadocs (PYE.html). Length is shown as — because v2.8.1 deprecated fixed maximum lengths in favour of conformance-profile constraints. Required and Table # are taken from the HL7 v2 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| PYE-1 | Set ID - PYE | si | — | R | — | — | Sequence number within the message |
| PYE-2 | Payee Type | cwe | — | O | — | — | Coded category of the payee |
| PYE-3 | Payee Relationship to Invoice (Patient) | cwe | — | O | — | — | Payee's relationship to the patient |
| PYE-4 | Payee Identification List | xon | — | O | — | — | Organizational identifiers for the payee |
| PYE-5 | Payee Person Name | xpn | — | O | — | — | Person name when the payee is an individual |
| PYE-6 | Payee Address | xad | — | O | — | — | Address to which payment is sent |
| PYE-7 | Payment Method | cwe | — | O | — | — | Coded method of payment delivery |
Most-used fields
- PYE-2 Payee Type drives downstream routing. Whether the payee is a provider, the patient, a guarantor, an assignee, or an estate dictates which sub-ledger an AR system posts to.
- PYE-4 Payee Identification List is the connecting key between the message and the receiver's payee master. Most billing engines reject PYE rows without at least one identifier here.
- PYE-5 Payee Person Name appears only when the payee is an individual; for organizational payees PYE-4's XON carries the name and PYE-5 is left empty.
- PYE-6 Payee Address must be a remit-to address, not a service or billing address. Several common postings errors trace back to confusing the two.
- PYE-7 Payment Method (check, EFT, wire, card) determines which downstream banking integration is invoked.
Version differences (2.6 -> 2.7 -> 2.8.2)
- v2.6 and earlier: No PYE segment. Payee data was either implicit (the billing provider was always paid) or carried in proprietary Z-segments alongside FT1.
- v2.7: PYE introduced with all seven fields shown above. The payee was finally distinguished cleanly from the guarantor (GT1) and the subscriber (IN1).
- v2.7.1: Editorial corrections; no structural changes.
- v2.8 / v2.8.1: No structural changes; vocabulary refinements in Payee Type and Payment Method tables.
- v2.8.2: PYE structure unchanged; minor clarifications on use with BAR messages.
Common mistakes
- Reusing the GT1 address in PYE-6. Guarantor address is for collections; payee address is for remittance. They are often different even when the parties are the same.
- Sending PYE for the default case. If the payee is the billing provider, most receivers expect PYE to be absent. A redundant PYE row can be misread as overriding the default.
- Mixing PYE-4 and PYE-5. PYE-4 is XON (organizational); PYE-5 is XPN (person). Senders sometimes stuff an individual's name into PYE-4's organization name field, which corrupts downstream payee matching.
- Omitting PYE-2. Without Payee Type, an AR system has no way to choose a sub-ledger and typically falls back to "miscellaneous", which obscures reporting.
- Treating PYE as repeating. PYE is non-repeating in v2.8.1; multiple payees for one transaction require separate financial transactions, not multiple PYE rows.
Examples
Minimal PYE
PYE|1|PROV^Provider^HL70557
Fully-populated PYE
PYE|1|PAT^Patient (Reimbursement)^HL70557|SELF^Self^HL70063|1004^Okafor Family Trust^^^^^XX^^^TR-1004|Okafor^Adaeze^M^^^^L|220 Cedar Ave^Apt 4B^Riverbend^OR^97001^USA^M|EFT^Electronic funds transfer^HL70570
Annotated breakdown
PYE Segment ID
|1 PYE-1 Set ID
|PAT^Patient (Reimbursement)^HL... PYE-2 Payee Type (CWE)
|SELF^Self^HL70063 PYE-3 Payee Relationship to Invoice (CWE)
|1004^Okafor Family Trust^^^^^XX.. PYE-4 Payee Identification List (XON)
|Okafor^Adaeze^M^^^^L PYE-5 Payee Person Name (XPN)
|220 Cedar Ave^Apt 4B^Riverbend... PYE-6 Payee Address (XAD)
|EFT^Electronic funds transfer^... PYE-7 Payment Method (CWE)
In-context excerpt: PYE inside a DFT financial message
MSH|^~&|BILLING|RIVERBEND|AR|RIVERBEND|20260612120000||DFT^P03^DFT_P03|MSG-DFT-7780|P|2.8.1
EVN|P03|20260612120000
PID|1||MRN-554120^^^Riverbend^MR||Okafor^Adaeze||19780214|F
PV1|1|O|CLINIC-CARDIO^^^RIVERBEND
FT1|1|TX-99181|TX-99181|20260612|20260612|CG|99213^Office visit^CPT|||1|125.00||CLINIC-CARDIO|9988^Reyes^Marta^L^^^MD
PYE|1|PAT^Patient (Reimbursement)^HL70557|SELF^Self^HL70063||Okafor^Adaeze^M^^^^L|220 Cedar Ave^Apt 4B^Riverbend^OR^97001^USA^M|EFT^Electronic funds transfer^HL70570
In-context excerpt: PYE designating a third-party billing service
MSH|^~&|BILLING|RIVERBEND|AR|RIVERBEND|20260612121500||DFT^P03^DFT_P03|MSG-DFT-7781|P|2.8.1
EVN|P03|20260612121500
PID|1||MRN-554121^^^Riverbend^MR||Nakamura^Hideo||19550901|M
PV1|1|I|3W^301^A^RIVERBEND
FT1|1|TX-99182|TX-99182|20260612|20260612|CG|99232^Subsequent hospital care^CPT|||1|212.00||3W|9988^Reyes^Marta^L^^^MD
PYE|1|ASN^Assignee^HL70557|OTH^Other^HL70063|7701^Cascade Revenue Partners^^^^^XX^^^TIN-771221334||PO Box 4422^^Portland^OR^97208^USA^P|CHK^Check^HL70570
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a segment-level ConceptMap for PYE. PYE conceptually maps to one of two FHIR targets depending on context:
Account.guarantorwhen PYE expresses the party financially responsible for an account.Claim.payeewhen PYE expresses the party to which an insurer's reimbursement should flow.
In both cases PYE-2 Payee Type translates to the type element on the target resource and PYE-4/PYE-5 resolve to a Reference(Organization) or Reference(Patient | RelatedPerson) as appropriate.
Engine considerations
- Cardinality: One PYE per financial transaction. Engines that flatten multiple PYE rows risk silently dropping payee information.
- Encoding: PYE-4's XON carries up to ten components; senders frequently omit the identifier-type-code component (XON.7), which causes payee-master matching to fall back on name string comparison.
- Validation: Strict profiles require PYE-1 and at least one of PYE-4 or PYE-5; lenient profiles accept PYE-1 alone, which is rarely useful.
- Order: PYE follows the FT1 it applies to; receivers should not reorder financial transactions and their associated PYE rows.
How Vorro parses and produces PYE
Vorro's HL7 parser links each PYE row to its preceding FT1 and exposes the pair as a single FinancialTransaction object with a resolved Payee sub-object. PYE-2 Payee Type and PYE-7 Payment Method are normalised against configurable code tables so downstream AR systems see primary values regardless of sender vocabulary. PYE-4 identifier components are split into structured fields, with the assigning-authority and identifier-type-code preserved exactly to support payee-master joins.
When producing PYE, Vorro emits the segment only when the payee differs from the default billing party for the source account; this avoids the redundant-PYE trap discussed under common mistakes. Person payees are routed through PYE-5 and organizational payees through PYE-4, never both, and remit-to addresses are taken from a distinct address slot than the guarantor's collections address.
