HL7^® Reference Guide

HL7 FT1 Financial Transaction

Examine the usage of every FT1 field from experience.

HL7 field reference FT1 fields from HL7 v2.5.1 Show fields

These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.

Fields

Field	Name	Required	Repeatable	Type	Table
FT1.1	Set ID - FT1	No	No	SI
FT1.2	Transaction ID	No	No	ST
FT1.3	Transaction Batch ID	No	No	ST
FT1.4	Transaction Date	Yes	No	DR
FT1.5	Transaction Posting Date	No	No	TS
FT1.6	Transaction Type	Yes	No	IS	0017
FT1.7	Transaction Code	Yes	No	CE	0132
FT1.8	Transaction Description	No	No	ST
FT1.9	Transaction Description - Alt	No	No	ST
FT1.10	Transaction Quantity	No	No	NM
FT1.11	Transaction Amount - Extended	No	No	CP
FT1.12	Transaction Amount - Unit	No	No	CP
FT1.13	Department Code	No	No	CE	0049
FT1.14	Insurance Plan ID	No	No	CE	0072
FT1.15	Insurance Amount	No	No	CP
FT1.16	Assigned Patient Location	No	No	PL	0079
FT1.17	Fee Schedule	No	No	IS	0024
FT1.18	Patient Type	No	No	IS	0018
FT1.19	Diagnosis Code - FT1	No	Yes	CE	0051
FT1.20	Performed By Code	No	Yes	XCN	0084
FT1.21	Ordered By Code	No	Yes	XCN
FT1.22	Unit Cost	No	No	CP
FT1.23	Filler Order Number	No	No	EI
FT1.24	Entered By Code	No	Yes	XCN
FT1.25	Procedure Code	No	No	CE	0088
FT1.26	Procedure Code Modifier	No	Yes	CE	0340
FT1.27	Advanced Beneficiary Notice Code	No	No	CE	0339
FT1.28	Medically Necessary Duplicate Procedure Reason.	No	No	CWE	0476
FT1.29	NDC Code	No	No	CNE	0549
FT1.30	Payment Reference ID	No	No	CX
FT1.31	Transaction Reference Key	No	Yes	SI

FT1 is where the billable detail starts to get serious. It is the segment that says "this thing happened, here is the charge or payment or adjustment, here is the code, here is the amount, and here is enough context for patient accounting to do something sensible with it". It is not glamorous, but when FT1 is wrong, money goes missing, patients get odd statements, and revenue-cycle teams start asking very pointed questions.

You mostly see FT1 in DFT messages, especially DFT^P03, where clinical systems, order fillers, department systems, pharmacy systems, theatre systems, or interface engines send charge detail to a billing or patient accounting system. It can also show up near orders and results, but the common mental model is still charge posting: one FT1 per financial transaction line.

The thing to keep in mind is that FT1 is not the same as IN1 or GT1. Insurance says who may cover the patient. Guarantor says who is financially responsible. FT1 says what financial event needs to be posted. It can carry diagnosis and procedure context, but it should not become your whole clinical record. Use DG1, PR1, ORC, OBR, and OBX for the clinical story, then let FT1 carry the billing line.

That example is longer than a lot of real charge messages, but it shows the important shape. The charge has a transaction type, a transaction code, a date, a quantity, an amount, a department, provider context, diagnosis/procedure context, and something to tie it back to the order or pharmacy record. Those are the fields that make reconciliation possible. I like opening these in HL7 Soup Web before writing any transform, because a single shifted FT1 field can quietly turn a dollar amount, department, or diagnosis pointer into nonsense.

Where FT1 actually earns its keep

The obvious use is a charge feed. A lab performs a test, radiology completes a study, pharmacy dispenses or administers a drug, a clinic posts a procedure, or an ADT system records a deposit. The receiving accounting system does not just need to know that something happened. It needs to know which charge code, how many units, which date, which department, which patient account or visit, which provider, and sometimes which diagnosis supports medical necessity.

FT1 is also where duplicate handling becomes a real design decision. If the sender resends yesterday's batch, should the receiver reject duplicate transaction IDs, replace existing charge lines, or post a reversal and a corrected line? There is no magic answer in the segment itself. You have to agree whether the feed is additive, corrective, or a full financial snapshot. Otherwise the interface will work beautifully until the first retry creates two charges for the same service. An engine such as Integration Soup is a good place to make that rule visible, so duplicates, reversals, and corrected lines are handled consistently instead of by memory.

Many systems bundle several FT1 segments in one DFT. That is fine, but it raises the question of atomicity. If one charge fails validation, does the whole message fail, or does the receiver post the good lines and reject one bad line? Good ACK and ERR behaviour matters a lot here, because billing people need to know exactly which transaction did not post.

This is the simple sequence number for FT1 segments in the message. If there are five charge lines, they are often numbered 1 through 5. It helps people and systems point at a particular line in the message, especially when an ACK or error needs to say "the third FT1 is bad".

Do not treat it as the durable charge ID. If the same transaction is re-sent tomorrow and it lands in a different order, FT1-1 may change. Use FT1-2 for the transaction identifier, and use FT1-31 carefully when linking a payment back to a charge line in an e-claim style workflow.

This is one of the fields I look for first when debugging a charge interface. It should be the sender's stable identifier for this financial transaction, not just another sequence number. A good transaction ID lets the receiver detect duplicates, support reversals, answer errors, and reconcile what was sent with what posted.

In v2.5.1 it is ST, so older feeds often send a plain text value. Newer HL7 versions move this toward CX, which says something about how important assigning authority becomes. If two systems can both generate "12345", then "12345" is not enough. The interface agreement should say whether FT1-2 is globally unique, unique per sending application, unique per batch, or only unique within a visit. Those are very different promises.

This is the batch or run that the transaction belongs to. It is useful for end-of-day charge batches, department extracts, retry files, and audit reports. When accounting says "we did not get the Wednesday lab batch", this is the kind of value that can save a lot of hunting.

It should not replace the transaction ID. A batch can contain many FT1 lines, and the same batch may be resent. Treat FT1-3 as a grouping label, not as proof that a charge is unique.

This required field is the date, or date range, for the transaction itself. In plain charge feeds it is usually the service date and time: when the test was performed, the drug was administered, the supply was used, or the chargeable event occurred. Because the data type is DR, it can represent a range, which matters for bed charges, recurring services, or period-based billing.

Do not confuse this with the posting date. If the lab test happened on Monday but the charge file was generated on Tuesday, FT1-4 should usually be Monday and FT1-5 should be Tuesday. That split is important for cutoffs, claims, revenue recognition, and the inevitable "why did this charge post in the wrong month?" conversation.

This is when the financial transaction was sent or posted to the financial system. Some receivers use it for accounting period control, batch balancing, or late-charge reporting. Others ignore it and derive posting time from message receipt.

Be explicit in the interface spec. If this field means "created in the source system", "sent by the interface engine", or "accepted by billing", those are different clocks. Finance teams care about dates in a way clinical systems sometimes underestimate.

This required field says what kind of money movement this line represents. The common HL7 values are CG for charge, CD for credit, PY for payment, AJ for adjustment, and CO for co-payment. It is a small code, but it changes the meaning of almost everything else on the line.

The trap is mixing transaction type and sign. Some systems send a credit with a positive amount and rely on FT1-6 to make it subtract. Some send a negative amount. Some do both, which is how one refund becomes a charge. Agree the rule. For a billing interface, "CG with 100.00" and "CD with 100.00" may be clearer than "CG with -100.00", but the only correct answer is the one both systems implement the same way.

This is the main charge code. In many sites it is a local charge master or CDM code. In other feeds it may be a test code, supply code, procedure-like code, or department-defined billing code. HL7 describes it as the code assigned by the institution to identify the transaction, such as a procedure, supply item, or test for charging purposes.

Make this coded element do its job. Send the identifier, text, and coding system, for example 80048^Basic metabolic panel^CDM or a local code with a clear local system name. Do not rely on FT1-8 as the only description. The receiver needs a stable code that maps to its billing rules, fee schedules, revenue codes, or claim lines.

This is also where charge-code governance matters. If a department changes a local code, does the interface know? If two departments use the same code for different things, is FT1-13 needed to disambiguate it? A lot of FT1 pain is not HL7 syntax. It is charge master maintenance leaking into an interface.

This is the human-readable description of the transaction. In later versions of the standard it is mostly kept for backward compatibility because FT1-7 already has a text component. Still, older billing systems and reports often display this field directly.

Use it to help humans, not to carry the code. "Basic metabolic panel" is fine. "80048 Basic metabolic panel, billed under plan A, repeat lab" is too much. If the receiver needs structured billing logic, put it in the proper fields.

This is an alternate description. It may be used for another language, a payer-specific display, a legacy description, or a department label. Many interfaces leave it empty.

If you use it, define whose alternate description it is. Source-system display text, patient-statement text, payer text, and internal accounting text are not the same audience.

Quantity is deceptively important. It is the number of billing units for the transaction. That may be one lab test, two drug units, fifteen minutes, one supply item, or a bed-day count depending on the transaction code and local billing rules.

Do not assume this is the clinical dose. Pharmacy is the classic trap. A patient may receive 500 mg, but the billing unit might be two HCPCS units, one vial, or a number of NDC units. If quantity is wrong, the amount may be wrong even when the charge code looks perfect.

This is the line total. If quantity is 2 and the unit amount is 14.00, the extended amount is usually 28.00. It uses CP, so the money component can carry a currency as well as the numeric amount.

Receivers often validate this field against quantity and unit amount. Decide which side is authoritative. Some interfaces send all three and expect the receiver to trust the extended amount. Others send quantity and unit price and let billing calculate the total. The worst version is when all three are sent but disagree.

This is the price per billing unit. It is not necessarily the internal cost and not necessarily the final patient responsibility. It is the unit amount used for this transaction line.

Use it when the receiver needs to calculate or validate totals. If the receiving system has its own fee schedule and only wants code plus quantity, it may ignore this. That is fine, as long as both sides know who owns pricing.

This field identifies the department or cost centre controlling the transaction code. In the real world, this is often lab, radiology, pharmacy, clinic, theatre, emergency, or another accounting department.

It can be a quiet but critical field. The same charge code may map differently by department, and finance teams often report revenue by department. If your charge code is only unique within a department, FT1-13 is not optional in practice, even if the base standard says it is optional.

This links the transaction to an insurance plan. It is useful when the charge line needs to be associated with a specific payer or coverage, especially where one visit has multiple coverages or where professional and facility charges split differently.

Do not use it as a substitute for IN1. IN1 carries the insurance story. FT1-14 is a charge-line pointer to the plan this transaction should use. If the plan ID here disagrees with IN1, somebody will have a bad billing day.

This is the amount associated with insurance for the transaction. Depending on the workflow, it may represent expected insurance responsibility, paid amount, or another payer-related amount. Many charge feeds leave it blank because adjudication happens later.

If you populate it, be precise. A submitted charge, expected reimbursement, contractual adjustment, insurance payment, and patient balance are different financial facts. FT1-15 should not become a vague "some amount the payer might care about" field.

This is the location associated with the transaction. For hospital charging, location can affect departments, cost centres, accommodation charges, facility billing, and reporting. It may also help reconcile a charge to where the patient was when the service happened.

Be careful when the patient moves. PV1 shows the visit location at the message level, but FT1-16 can say the charge-line location. If a patient moved wards during the day, a bed charge and a lab charge may legitimately point at different places.

This selects the fee schedule for the transaction. That might be a public/private schedule, a payer schedule, a contract schedule, or a local pricing rule. Many systems do not send it because the receiver derives the schedule from payer, plan, patient type, department, or date.

Only send it if it actually controls pricing downstream. A stale fee schedule code is worse than no code because it can quietly make the receiver choose the wrong price.

This is the billing patient type for the transaction. HL7 calls out that it is for use when the billing patient type differs from the visit patient type in PV1. That is the whole point of the field.

If the patient type is already clear in PV1 and billing does not need a separate value, leave this alone. If billing rules distinguish outpatient clinic, emergency, day stay, inpatient, research, or private billing categories differently from the clinical visit, then FT1-18 may matter.

This repeats and carries diagnosis codes associated with the transaction. It is commonly about medical necessity, claim support, or linking a charge line to the diagnosis that justifies it. Use a real coding system in the third component, such as ICD-10-CM where that is the profile's rule.

Do not confuse this with a full diagnosis list. DG1 is where the diagnosis story normally lives. FT1-19 is the diagnosis context for this financial transaction. If a visit has ten diagnoses but only one supports this lab charge, sending all ten here may not help the billing system.

This identifies the person or group that performed the service, procedure, test, or transaction. In charging, provider identity can affect claims, attribution, reporting, fee schedules, and compliance. Use a provider identifier where possible, not just a display name.

One subtle point from the standard: repetitions can be used for multiple identifiers for the same practitioner, not necessarily multiple different practitioners. If your local rule uses repeats for multiple performers, document that clearly. Otherwise someone may read repeats as alternate identifiers and lose the team information.

This is the ordering provider or group. It is not the same as performed by. In lab, radiology, pharmacy, and procedures, the clinician who ordered the service and the person or department that performed it may be completely different.

Billing systems often care about both. A claim may need an ordering/referring provider, while the service line may also need a rendering or performing provider. If those concepts are collapsed into one field, your interface may appear to work until payer edits start rejecting claims.

This is the cost of a single item. That wording matters. Cost is not always price, charge, or reimbursement. It may be an internal costing value rather than the amount billed to the payer or patient.

Some systems do not want internal costs flowing through ordinary DFT messages. If you use this field, make sure finance, compliance, and the receiver agree what kind of "cost" is being sent. Do not duplicate FT1-12 here unless the business meaning really is the same.

This links the financial transaction back to the filler order, result, pharmacy, or departmental order number. It is a practical reconciliation field. If a billing user asks "which lab order created this charge?", this is often where you want to look.

Use the same identifier discipline you would use in OBR-3. Include enough assigning context that the receiver can tell whether ORD4488 is a lab order, radiology order, pharmacy dispense, or something else.

This is the person who entered the financial transaction. Sometimes that is a billing clerk, sometimes a department user, sometimes the system account that generated the charge.

It is mostly an audit and support field. Do not use it as the ordering provider or performing provider unless that is genuinely the same person. If a charge has to be corrected, this field can be useful for finding the workflow that created it.

This is the procedure code associated with the financial line. In claims-style work it may be a CPT, HCPCS, or local procedure code depending on the country and implementation guide. It is not always the same as FT1-7. FT1-7 may be a local charge code, while FT1-25 may be the billable procedure code that appears on the claim.

Get this distinction right. If your source system only has one code, decide whether it belongs in the transaction code, the procedure code, or both. If it is sent in both, make sure the receiver knows which one drives posting and which one drives claim coding.

Modifiers refine the procedure code. They can mean repeat procedure, bilateral procedure, professional component, technical component, distinct procedural service, or a local billing variation. The exact meaning depends on the code set and payer rules.

Do not glue modifiers onto the procedure code text if the receiving system expects FT1-26. Send each modifier as its own repeat and preserve the code system. Order can matter in some billing contexts, so do not casually sort them unless the trading partner tells you to.

This is the ABN-style field. The table includes cases such as the service being subject to medical-necessity procedures, the patient being informed and agreeing to pay, the patient asking that the payer be billed, or the notice not being signed.

Treat this as a financial/legal workflow flag, not a casual comment. If a patient may be responsible because medical necessity is uncertain, the billing system needs the right code and the organisation needs the right documentation behind it.

This is for the awkward but real situation where a duplicate-looking procedure is medically necessary. Think repeat lab, repeat imaging, repeat treatment, or a second service on the same day that could otherwise be rejected as a duplicate.

Most interfaces leave it empty. If your payer or local billing rule needs it, do not hide the reason in NTE. Use the coded field so the downstream claim logic can see it.

This matters for drug-related charges. The NDC identifies a specific drug product and package, while FT1-25 or FT1-7 may carry the HCPCS, charge, or procedure-style code. Those are not interchangeable. A ceftriaxone administration charge may need both the HCPCS code and the NDC product detail.

NDC format is a common source of trouble. The FDA describes NDCs as unique three-segment identifiers for drugs, and payer billing workflows often want a normalized billing format rather than the exact package label formatting. If the receiver expects 11 digits without hyphens, do not send a pretty label code with dashes. Also remember that an NDC being listed does not by itself mean it is covered or reimbursable.

This identifies a payment reference. It may point to a receipt, remittance, payment transaction, external payment processor reference, or another financial identifier depending on the workflow.

It is more common in payment or adjustment workflows than in simple charge posting. If you use it, agree which payment system owns the identifier and whether it can be used to trace refunds, reversals, and partial payments.

This is used to link a payment to the corresponding charge in an e-claim style workflow. In practice, it often refers back to the FT1 set ID or the relevant financial line being paid, credited, or adjusted.

Be careful with it because FT1-1 is only a message-local line number. If a receiver needs durable linking across messages, FT1-2 or another stable transaction identifier may be safer. The reference key is useful, but only if everyone agrees what it references.

What about newer FT1 fields?

Later versions of HL7 add quite a lot after FT1-31. The new fields are very telling: performing facility, ordering facility, item number, model number, special processing code, clinic code, referral number, authorization number, service provider taxonomy, revenue code, prescription number, NDC quantity and unit of measure, and a block of durable medical equipment certification fields.

That tells us where FT1 has been stretched over time. Modern billing wants more than a charge code and amount. It often wants facility, authorization, revenue code, medication package detail, prescription linkage, and medical necessity documentation. This page follows the v2.5.1 field list used by our local reference data, so the formal table stops at FT1-31, but if you work with v2.9 profiles, do not be surprised when those later fields appear.