Back-allocation is the working mechanic at the center of production allocation: the actual arithmetic that takes one accurately measured total and pushes it backward across the wells that produced it. The direction is what gives it its name, because the reliable number lives at the sales point, downstream, and it is distributed upstream to the wellheads that were never measured that precisely. This guide explains how back-allocation uses well-test theoretical rates and an allocation factor to split a measured total, walks through a numeric example, and shows how SCADA well-test and metering data drive it.
Back-Allocation in one line: Back-allocation is the method of distributing a measured sales-point total backward across the individual wells that produced it, in proportion to each well's theoretical production. Each well's theoretical volume comes from its most recent well-test rate multiplied by its runtime, and the sum of theoretical volumes is compared with the measured total to derive an allocation factor. Multiplying each well's theoretical volume by that factor gives its allocated share, and because the factor is applied to every well, the allocated volumes always add back up exactly to the measured total.
Back-allocation starts from the one number that is trusted: the accurately measured volume at the sales or custody point over a period. That total is real but undifferentiated, so the method needs an estimate of each well's relative contribution to divide it. That estimate is the well's theoretical production, computed as its well-test rate, the rate measured the last time the well was routed to a test separator, multiplied by the time the well actually ran during the period.
Summing the theoretical volumes across all wells that route to the measurement point gives a theoretical total, which almost never equals the measured total exactly. The ratio between them, measured total divided by theoretical total, is the allocation factor, and it is the single adjustment that forces the estimates to agree with reality. Each well's allocated volume is then its own theoretical volume multiplied by that shared allocation factor.
Applying the same factor to every well is what guarantees the allocated volumes sum back to the measured total, so nothing is created or lost in the distribution. The theoretical rates decide how the total is split, the measured total decides how big the total is, and the allocation factor is the bridge that reconciles them. This is the essential mechanic that a full allocation process wraps context around.
Consider three wells routing to a common tank battery whose sales meter records 1,000 barrels of oil for the month. Well A last tested at 20 barrels per day and ran the full 30-day month, giving a theoretical 600 barrels. Well B tested at 15 barrels per day and also ran the full month, giving 450 barrels. Well C tested at 12 barrels per day but was down half the month, running only 15 days, giving 180 barrels. The theoretical total is 600 plus 450 plus 180, or 1,230 barrels.
The measured total is 1,000 barrels while the theoretical total is 1,230, so the allocation factor is 1,000 divided by 1,230, about 0.813. Each well's allocated volume is its theoretical volume times this factor: Well A gets 600 times 0.813, roughly 488 barrels; Well B gets 450 times 0.813, roughly 366 barrels; and Well C gets 180 times 0.813, roughly 146 barrels. Those three allocated volumes sum to 1,000 barrels, matching the measured total exactly, which is the property the shared factor guarantees.
The example also shows why runtime is as important as test rate. Well C tested at a healthy rate but, because it ran only half the month, contributed far less theoretical volume than a full-month well of similar rate, and its allocated share reflects that. Had the model assumed Well C ran the whole month, it would have claimed too much of the total at the expense of the wells that genuinely ran, which is why accurate per-well runtime is central to a correct back-allocation.
Back-allocation needs three streams of data kept current: each well's latest test rate, each well's runtime over the period, and the measured sales total. A cloud SCADA such as Merobix supplies all three from the field. Well-test measurements from a test separator can be captured and stored so the theoretical rate for each well is the genuine latest test rather than a stale figure, and header or sales-point meter readings provide the measured total, all read over Modbus, DNP3, OPC UA, or MQTT and historized.
Runtime is where continuous monitoring matters most, because it is the input most prone to error when captured by hand. A well's on/off state logged continuously yields exact runtime for any period, so a well that tripped for two days is credited with only the time it actually flowed. In the worked example, getting Well C's half-month runtime right was the difference between a fair split and one that over-credited a partly idle well, and only a continuous state record delivers that reliably.
With test rates, runtimes, and measured totals all historized in one place, the allocation factor and each well's allocated volume can be computed automatically and recomputed whenever a new well test, a corrected runtime, or a late meter reading arrives. The same data trail also makes each allocated number auditable back to the specific test, runtime, and sales measurement behind it. For an operator with many wells, automating this from live data is what turns back-allocation from a monthly spreadsheet chore into a routine, defensible calculation.
Back-allocation distributes an accurately measured sales-point total backward across the wells that produced it, in proportion to each well's theoretical production. Each well's theoretical volume is its latest well-test rate times its runtime, and the sum of theoretical volumes is divided into the measured total to get an allocation factor. Multiplying each well's theoretical volume by that factor gives its allocated share, and the shared factor ensures the shares add back up to the measured total.
Runtime scales each well's theoretical production, because a well's theoretical volume is its test rate multiplied by the time it actually ran during the period. A well that was down for part of the period contributes proportionally less theoretical volume and so receives a smaller allocated share. Getting runtime right is essential, because assuming a partly idle well ran the whole period would over-credit it and steal volume from the wells that genuinely produced, which is why continuous state data matters.
They almost never match because well-test rates are periodic snapshots that may not reflect the well's average behavior over the whole period, wells vary between tests, and small measurement and process losses accumulate. The mismatch is expected, and it is exactly why an allocation factor is calculated as the measured total divided by the theoretical total. Applying that factor scales every well's estimate so that the allocated volumes reconcile precisely to the trusted measured total.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.