Every owner number account entered into a revenue division of interest (DOI) must have a pay code given to it for that specific producing property. There are valid circumstances when an owner will have a particular pay code in one well, but a different pay code in another well. But that discussion is beyond the scope of this week’s blog and will be covered in future blogs.
When an owner has no issues outstanding that would prevent a payer (distributor of revenue) from paying the owner to protect itself from potential financial loss, the owner will be in “pay” status. When the owner has any title issue identified by company policy as presenting potential financial loss for the company, the owner’s account in that property is suspended. A code blocking the computer system from issuing payments to the owner, known as a suspense code, is entered for the owner in the DOI for that property with an effective date associated with it. Typically, there are only two pay codes needed for an owner placed in “pay” status: a code authorizing payments but restricting them to a minimum account balance threshold, and a code authorizing payment regardless of the account balance (when required by contract). The suspense codes are the area causing headaches.
Most companies have abandoned using the generic suspense code “S” to stop payments to an owner. On its face, an S code offers no clue as to why the owner was suspended. In addition to many other legal reasons, the S code is invalid for readily identifying escheatable funds (funds that qualify for payment to the proper state as unclaimed property), to avoid interest and penalties for late payment.
Since it’s necessary today to indicate why a revenue owner is suspended, what suspense code should be used? I’ve worked for companies that have 40 or more different suspense codes set up for use in a DOI. Quite often, they have multiple duplicates, groups of codes that mean the same reason for suspense. An example would be TP, TR, T1, T2, and T3 all meaning the same reason: transfer pending. Only one code should be needed. By the way, once a company has been place on constructive notice that a transfer has occurred, for example, an unrecorded copy of a deed, the company should not continue to pay the old owner because they will incur financial liability. Some companies have forbidden the use of a transfer-pending code, because sometimes accounts remain in that code for years and the company wants to avoid that for some reason. Those companies should rethink the issue and consider the unrecorded deed like a title opinion requirement. How often do accounts get put in suspense for title opinion requirements and remain in that suspense code for years and years, sometimes for the life of the well? More often than you think.
The real question is, how did so many suspense codes get set up in the database, anyway?
The most common reason is that they were imported into the system. When a company acquires properties from another company—by acquisition or merger—the Buyer often downloads the Seller’s DOIs for each of the properties, dumping them into an Excel file specifically created for data uploading later. That Excel file typically is then manipulated, directing certain codes found in the Seller’s data to be changed automatically to the Buyer’s codes before the Excel file is uploaded into the Buyer’s database. That manipulation is called data mapping, and functions much like the “find & change” function in an ordinary Excel spreadsheet. If the suspense code mapping is overlooked and not done, or is done incorrectly (causing the Buyer’s database to ignore the instruction), the Buyer’s database system imports the Seller’s codes and instantly duplicate codes now exist in the Buyer’s database. The number of duplicates can grow with each acquisition or merger.
Another reason for too many suspense codes is insufficient oversight of new suspense code setups. If all analysts are left to their judgment in a company due to lack of written policy and guidelines, over time it leads to an unnecessary expansion of suspense codes.
Once a specific pay code (meaning either a pay-type code or suspense-type code) is assigned to an owner in a DOI, audit restrictions require that it can’t be changed, except by a transfer process in the database, or by created a whole new DOI with the new pay code assigned (then requesting a reversal and rebook back to the effective date of the new pay code). Any funds accrued to that owner in that suspense code in that well DOI must be transferred to the new code. Sometimes that can be done by the division order analyst as part of the transfer process in the database, or it must be done by the accounting department using a reversal and rebooking procedure if a new DOI was created.
So, how can a database using dozens of suspense codes be fixed? Depending on the system, a painstaking and time-consuming process of systematic transfers from the unwanted code to the wanted code would be necessary. Even a mass transfer would not be without disruptive problems.
Most companies opt to keep using the unwanted codes in current properties, but disallow using those codes in future transfers or new DOIs. Natural attrition eventually eliminates the unwanted codes from active DOI records. At least, until the next acquisition or merger…
Next week’s blog will be “Common DOI Management Issues: Interest Types.”
