A transaction is a story across systems.
The order, the invoice, and the accounting entry each show part of the story. Understanding the relationships is what makes the whole useful.
Enterprise systems tend to organize information around the record each application owns. A customer relationship, an order, a subscription, an invoice, and an accounting entry may all be well defined inside their individual platforms. The harder problem is understanding how they relate.
That relationship matters when someone asks a practical question: why did this amount change, where did this discrepancy begin, or which downstream records could be affected?
Connect the business meaning.
Moving a reference identifier between applications is useful, but it does not capture every relationship. A contract amendment can affect several subscriptions. A usage adjustment can alter a charge. A billing correction can have consequences in accounting. The architecture needs a way to preserve those business connections.
Keep change in the picture.
A transaction story also has a timeline. The information available when a decision was made may differ from what is visible today. Understanding both the relationships and the sequence of changes makes explanations more useful for operations, finance, and review.
Make the connections useful to people.
The purpose of lineage is to help someone act: trace a discrepancy, understand an exception, evaluate an impact, or check a decision. That means the relationships need to be presented in the language of the business, with enough detail for a person to inspect the underlying records.
This is one of the connections I find most valuable between enterprise architecture and financial intelligence. When the transaction story is accessible, teams have a stronger basis for understanding what happened and deciding what to do next.