Most Salesforce reporting problems in midstream are not report problems. They are data-model problems wearing a reporting costume, and the model almost always fails at the same place: the contract.
Model the contract as its own object
In midstream, the contract is the center of gravity, not the opportunity. A gathering, processing, or transportation agreement has terms, rates, minimum volume commitments, and a life that spans years and many transactions. Trying to represent it as a closed opportunity flattens all of that into a single moment.
Give the contract its own object with its own lifecycle, and let opportunities represent the pursuit while the contract represents the living agreement. Everything downstream, volumes, invoices, renewals, hangs off the contract.
Separate the agreement from the volumes
The single most useful modeling decision in midstream is separating contract terms from measured volumes. Terms are relatively static, rate, commitment, location, counterparty. Volumes are a high-frequency stream of measured quantities over time.
Put volumes in a related child object keyed by date and location, and you can report actuals against commitments, spot shortfalls, and calculate deficiency charges without contorting your data. Collapse them together and every volume question becomes a spreadsheet export.
Give locations and points first-class identity
Midstream is a business of physical points, receipt and delivery points, meters, plants, interconnects. If these live as free-text fields, your reporting will drown in “Station 4” versus “Sta. 4” versus “Station #4.”
Model locations as their own records with stable identifiers, and reference them from contracts and volumes. This is unglamorous work that pays off every single time someone asks “what moved through this point last quarter.”
Represent commitments so the system can check them
A minimum volume commitment is only useful if the system can compare it to actuals automatically. Store the commitment as structured data, quantity, period, make-up rights, alongside the volumes it governs, so a rollup or a scheduled process can flag when a counterparty is running short.
If checking commitments requires a human with a spreadsheet, it will happen late and inconsistently, which is exactly when deficiency revenue leaks.
Keep counterparties clean and connected
Counterparties in midstream are often related, parent producers, affiliated shippers, joint ventures. Model those relationships explicitly rather than duplicating accounts, so exposure and volume can roll up to the entity that actually matters for credit and negotiation.
A clean account hierarchy is worth more than any dashboard, because every dashboard is only as trustworthy as the accounts beneath it.
Design for the questions you'll be asked
Before building, list the questions the business will bring to this model: volume by point, actual versus committed, revenue by contract, exposure by counterparty, upcoming renewals.
If the data model can answer those with standard reports and rollups, it's right. If any of them require an export and a pivot table, the model is wrong, and no amount of report-building will fix it. Design backward from the questions.
The takeaway
Midstream data modeling comes down to giving contracts, volumes, locations, and counterparties each their own honest structure instead of forcing them into the opportunity object. Separate static terms from high-frequency volumes, make physical points real records, and store commitments so the system can check them. Get that foundation right and reporting becomes almost boring, which, for revenue you're supposed to be tracking, is exactly what you want.