The RRC oil and gas ledgers (and why PDQ is usually what you want)

Search for "rrc oil ledger" and you will find a row on the Commission's downloads page, a record layout called OLA013K, and very little explanation of what the thing is or whether you want it. This article is the explanation. The short version: the ledgers are the Railroad Commission's proration ledgers — the mainframe's own view of what each lease was allowed to produce and what it did produce — and they are the right file for a narrow set of questions about allowables and balances. For the broad question, "how much oil and gas did Texas produce", the Production Data Query tables answer it in a format you can open, and the ledgers do not.

Six files, three families

The Commission publishes production in the mainframe ledger format six ways, and they sort into three families by what window of time they cover.

The proration ledgers — a rolling year.

• The oil ledger, layout OLA013K: for every oil lease, twelve months of production and fourteen months of allowable, with the balances the Commission carries forward. RRC splits it by district and lists each file as its own row on the downloads page; the pieces share one layout and one folder, so EZRRC catalogues them as one dataset where a download names its volume.
• The gas ledger, layout GSA020K: the same shape for gas, keyed on the gas well ID rather than the lease, because gas is prorated per well. It comes in three files by district group — Districts 1 to 3, Districts 4 to 6 and 6E, and 7B through 10.

Both are published monthly and are available by the 20th. Both are a window, not a history: each month the oldest month falls off the back.

The historical ledgers — the long series.

• Historical ledger, statewide oil and statewide gas, layout LAD001: monthly production from 1993 to the present, statewide, in the ledger format. Monthly, available by the 27th.

The statewide production files — two years.

• Statewide production data, oil and gas, layout PDA001: a rolling twenty-four month window of production plus allowable across the state. Monthly, by the 27th. The window rolls; this is not a history either.

There is a seventh cousin worth knowing about, the PR gas disposition file — OGA0861, a 200-byte record per gas well per month carrying where the gas went, from the same older reporting system — which arrives in both ASCII and EBCDIC editions that are the same records byte for byte once decoded.

Why the ledgers look the way they do

Every file in the three families is EBCDIC, with packed-decimal numbers and implied decimal places. That is three separate obstacles between you and a number, and each is a solved problem, but they have to be solved in order.

EBCDIC is IBM's mainframe character encoding; a ledger opened in a text editor is a screen of accented capitals and @ signs, and nothing is wrong with it. What is EBCDIC covers the decoding, which for the text fields is a one-line transcode from code page 037.

Packed decimal is the harder part, because it is not text at all. A COBOL field declared COMP-3 stores one decimal digit in each half-byte — each nibble — with the sign in the very last nibble: C or F for positive, D for negative. So a twelve-digit production volume occupies seven bytes that transcode to garbage and have to be unpacked instead. The whole decoder is a hex dump read as digits:

from decimal import Decimal

def unpack_comp3(raw: bytes, scale: int = 0) -> Decimal:
    """Decode a COBOL packed-decimal (COMP-3) field to a Decimal."""
    nibbles = raw.hex()                     # one hex character per nibble
    digits, sign = nibbles[:-1], nibbles[-1]
    value = int(digits or "0")
    if sign in ("d", "b"):                  # D and B are the negative signs
        value = -value
    return Decimal(value).scaleb(-scale)

Every nibble but the last is a digit; the last is the sign, and raw.hex() keeps them one character each so the sign is always the final character. Two bytes 12 3C decode to 123 and 12 3D to -123. A real ledger field declared PIC S9(9)V99 COMP-3 is six bytes — eleven digits and a sign — so the bytes 00 00 12 34 56 7C decode with scale=2 to 12345.67, and the same bytes ending 7D to -12345.67. Run those three before you run the file.

The scale argument is the third obstacle. In PIC S9(9)V99 the V is an implied decimal point with two digits after it, and no decimal point exists in the bytes. Read the number as an integer and every volume is a hundred times too big. Fixed-width files and COBOL record layouts walks through PIC clauses and implied decimals in general; the ledger layouts are the place where all of it shows up at once.

EZRRC does not parse these files. Upstream has not built a reader for them yet, so the catalogue documents each one, links the record layout, and serves the Commission's original bytes — the pristine file, as published — rather than pretending to serve rows it does not have. If you download a ledger you are downloading EBCDIC, and the three steps above are yours.

What only the ledgers can tell you

Given all that, why would anyone want them? Because they are the proration system's own books, and a few things live only there.

Fourteen months of allowable against twelve of production. The allowable is the regulatory ceiling — how much a lease or gas well was permitted to produce in a month — and the ledger carries it two months further forward than the production it sits beside. If your question is about the ceiling rather than the output, the ledger has allowable months that a production table does not.

Carried balances. A lease that produced under its allowable carries an underproduction balance forward; one that produced over carries an overproduction balance. Those running balances are the ledger's reason to exist, and the ledger is where the Commission publishes them as it carries them. If you are trying to find leases running an overproduction balance, or to follow one lease's balance month by month, this is where.

The gas well as the unit. The gas ledger is per gas well ID, which is the grain gas is actually regulated at, with the same allowable and balance columns.

The Commission's own encoding. A handful of subscribers feed these files into systems that expect exactly this format, which is why the RRC still publishes them, and why the twenty-four-month statewide files exist alongside everything else.

That is a real list, and it is a short one.

Why PDQ is usually what you want instead

For every other production question, the PDQ lease production table — one of the sixteen tables inside the Production Data Query dump — is the better download, and it is not close.

• It covers the same period as the historical ledgers, from 1993 to the present, at the lease grain, and it is delimited text with a header row that EZRRC has already parsed into 76 million queryable rows. The historical ledgers cover 1993 onwards too; they just do it in EBCDIC.
• It carries the allowable beside every monthly volume — for oil, gas, condensate and casinghead gas — and the ending balance for oil and condensate. The current-month allowable most people are after is there without unpacking anything.
• It carries the four products. The ledgers are split oil and gas; PDQ has oil and condensate, gas and casinghead gas, on the same row.
• The volumes are whole numbers in the reporting unit — barrels for liquids, MCF for gas — with no implied decimals, unlike the ledgers.
• It is filterable here. A county, an operator, a field or a cycle range comes back as a CSV, an Excel file or Parquet in minutes. Downloading production by county, lease, operator and district is the recipe.

The trade is that PDQ is a snapshot of a moving system: the newest two or three months are always incomplete and only ever go up as amended reports arrive, and production data explained is about handling that. The ledgers have their own version of the same lag, and it is harder to see because you cannot query them.

Choosing, in one table

If you do take a ledger, do it deliberately: download the volume for your district, keep the record layout beside it, decode in the order above, and check your first few decoded rows against the same lease's PDQ row before you trust a number. Where a ledger and PDQ describe the same month for the same lease they should agree on production; the ledger's extra columns are the reason you came.

Next: drilling permits — the fastest-moving data the RRC publishes and the most over-interpreted.