VWAP disagreements are often anchor disagreements

VWAP sounds like one calculation until two correct scripts disagree. Then the argument usually moves to formulas. The formula matters, but many VWAP disagreements are really anchor disagreements. Session VWAP, anchored VWAP, weekly VWAP, event VWAP, and custom reset VWAP are not the same measurement.

It keeps coming up because users often ask why their VWAP does not match another chart. The answer is rarely “one of them is stupid.” More often, they are measuring different windows or using different source assumptions.

Why this catches people

The pattern that causes trouble is treating VWAP like a moving average with volume. It is not just a smoothed price line. It is volume-weighted price over a defined accumulation window. Change the reset point and the line changes. Change the source price and the line changes. Change the session definition and the line changes.

Anchored VWAP makes this even more visible. The anchor can be a session start, a swing, an earnings event, a manual timestamp, or a structural break. The calculation after that point may be standard, but the choice of anchor is a trading idea.

The Pine bit

In Pine, I want the script to make the anchor visible. If the VWAP resets at the session, call it session VWAP. If it resets on a pivot, call it pivot-anchored VWAP and show the pivot rule. If it uses a higher-timeframe session boundary, make the timing decision explicit.

The source also matters. Typical price, close, hlc3, and chart-context prices can all produce different results. On synthetic charts, the source question becomes even more important.

newSession = ta.change(time("D")) != 0
var float pv = 0.0
var float vv = 0.0

if newSession
    pv := 0.0
    vv := 0.0

pv += hlc3 * volume
vv += volume
customVwap = vv > 0 ? pv / vv : na

How I handle it in builds

For client indicators, I avoid showing several VWAPs without clear labels. A cluster of lines can look authoritative, but if the user cannot tell which anchor each line uses, the tool becomes decoration. The label should say session, week, month, event, pivot, or manual anchor.

I test against TradingView built-ins only after matching the anchor, source, session, and chart type. Comparing unmatched VWAPs produces noise, not proof.

Where this shows up

A useful check is to write the anchor time directly on the chart. If two VWAPs disagree, compare their first accumulated bar before comparing their current value. If the start point differs, the disagreement is already explained. The formula can be perfect and still produce a different line because the memory window is different.

I avoid calling every custom VWAP “the VWAP.” That phrasing invites false comparison. Session VWAP, anchored VWAP, weekly VWAP, and event VWAP deserve different labels. The label is not decoration. It tells the user what population of trades the line is summarizing.

I check how the VWAP handles missing or unusual volume. Some markets, symbols, or chart contexts can make volume less straightforward than expected. A VWAP that divides by an accumulated volume total should guard against zero or unavailable volume rather than letting the plot imply a meaningful line.

In client tools, I prefer fewer VWAPs with better labels over many lightly explained lines. The user should know which line answers which question.

How I test it

I test VWAP by matching anchor, source, session, and chart type before comparing values. If any one of those differs, the comparison is not a validation. It is just two related calculations drawn on the same chart.

Checks before I trust it

• Identify the anchor before comparing VWAP values.
• Match source price, session, timeframe, and chart type when validating.
• Label anchored VWAPs by the event or rule that created them.
• Avoid treating VWAP as just a volume-weighted moving average.
• Be careful using VWAP on synthetic charts without reviewing the source context.

What matters here is that VWAP is not one line. It is a calculation plus a memory window. Most disagreements become clear once the memory window is named.