diff --git a/content/blog/2026-05-18-billing-question-third-quarter-not-first.md b/content/blog/2026-05-18-billing-question-third-quarter-not-first.md
new file mode 100644
index 0000000..e733305
--- /dev/null
+++ b/content/blog/2026-05-18-billing-question-third-quarter-not-first.md
@@ -0,0 +1,78 @@
+---
+title: "The Billing Question Gets Asked in the Third Quarter, Not the First"
+date: 2026-05-18
+pillar: "The Merchant-Side Gap"
+tags: [governance, scope, billing, post-launch, merchant-side]
+linkedin_copy: |
+  The engagements that surprise you with a billing reconciliation in month nine all have the same origin story. It starts in month one, when a developer fixes something outside the contracted scope because it is faster than filing a change request.
+  
+  Each instance is small. A quick integration tweak. A vendor call the SOW does not cover. A minor enhancement someone mentioned in a standup. Nobody tracks it because it feels like good service.
+  
+  By month three, the engagement has a shadow scope. The merchant expects a level of support that was never priced. The delivery team does not think of it as free work. They think of it as being responsive. The billing spreadsheet has not been opened yet. When it finally is, the gap between contracted scope and delivered scope is already significant.
+  
+  Correction is harder than prevention. The merchant has received three months of a certain service level. Pulling it back feels like a downgrade. The delivery team has been doing good work. Telling them to stop helping feels punitive. So the correction gets softened, the shadow scope shrinks but persists, and the cycle continues.
+  
+  The merchant-side gap: the buyer almost never knows this is happening. They see a responsive team. They do not see that the responsiveness is partially subsidized by unbilled hours. Most merchant-side leaders, if told their partner was absorbing unscoped work, would want to know. Not to pay more. To make better decisions about real support needs and internal staffing.
+  
+  The fix is shorter feedback loops. Weekly scope reconciliation, not quarterly. A monthly scope summary sent to the merchant showing what was in scope and what was adjacent. A ten-second decision framework for the delivery team: log it and flag it before you do it.
+  
+  If you are on the merchant side, ask your partner one question: "What did your team do last month that was not in our SOW?" If they can answer precisely, your engagement is well-governed. If they hesitate, you have a billing question about to surface.
+  
+  Full post: {{url}}
+---
+
+Here is a pattern I have seen repeat on enough engagements to call it structural.
+
+A commerce implementation goes live. The build team transitions to a run-the-business support model. The SOW covers a defined scope of monthly hours and a defined set of responsibilities. For the first month or two, everyone is heads-down on stabilization. Scope questions are academic. The work is obvious: fix the bugs, tune the integrations, keep the site running.
+
+Then the stabilization settles. The work shifts from reactive to discretionary. And a quiet pattern starts.
+
+A developer fixes something outside the contracted scope because it is faster than filing a change request. A technical lead takes a call with a third-party vendor the SOW does not cover because the merchant asked and it seemed helpful. Someone builds a small integration enhancement that was never scoped because the merchant mentioned it in a standup and it only took a few hours.
+
+Each instance is small. Each instance is well-intentioned. Each instance is invisible to billing.
+
+## The compounding problem
+
+By month three, the engagement has a shadow scope. The merchant now expects a level of service that was never priced. The team delivering it does not think of it as free work. They think of it as being responsive. The project manager may not even know it is happening because the work items are too small to surface in a sprint review.
+
+The first time someone opens the billing spreadsheet and compares contracted scope to delivered scope, the gap is already significant. Not because anyone acted in bad faith. Because the feedback loop between work delivered and work billed was never shorter than ninety days.
+
+Ninety days is long enough for a pattern to calcify into an expectation.
+
+## Why correction is harder than prevention
+
+Once a merchant has received three months of a certain scope of service, telling them that scope was never part of the contract is a relationship conversation, not a billing conversation. They did not ask for free work. They asked for help, and help showed up. From their perspective, this is what the engagement looks like. Pulling it back feels like a downgrade.
+
+The delivery team faces the same problem in reverse. They have been doing good work. Telling them to stop helping feels punitive. A governance review that surfaces the gap reads as blame, not as process improvement.
+
+So the correction gets softened. "Going forward, we will be more careful about scope." The shadow scope shrinks a little but does not disappear. The next quarterly review surfaces the same pattern at a smaller scale. The cycle continues.
+
+## What the merchant never sees
+
+Here is the part that lands in the merchant-side gap.
+
+The buyer almost never knows this dynamic exists. They see a team that is responsive and helpful. They do not see that the responsiveness is partially subsidized by unbilled hours. They do not see that the team's capacity for their contracted work is being consumed by work that is not on anyone's books.
+
+If you told most merchant-side leaders that their implementation partner was quietly absorbing scope that should be billed, most would want to know. Not because they want to pay more, but because they want an honest accounting of what the engagement actually requires. A merchant who understands the true scope of their support needs can make better decisions about internal staffing, vendor selection, and budget planning.
+
+The information asymmetry hurts both sides.
+
+## The structural fix
+
+The fix is not "bill more aggressively." The fix is shorter feedback loops.
+
+Weekly scope reconciliation, not quarterly. Every Friday, someone compares the work delivered to the work contracted. Not a forensic audit. A fifteen-minute check: did anything get done this week that is not in the SOW? If yes, log it. Decide whether to bill it, absorb it, or add it to the next scope review. The important thing is that the decision is conscious, not accidental.
+
+A monthly scope summary sent to the merchant. Not an invoice. A summary. "Here is what we did this month. Here is what was in scope. Here is what was adjacent." This does two things. It gives the merchant visibility into the real workload. And it creates a natural moment to discuss whether the adjacent work should be formally scoped.
+
+A defined escalation path for the delivery team. When a developer gets a request that falls outside scope, they need a ten-second decision framework. Not "say no." Just "log it and flag it before you do it." The logging is the intervention. Most shadow scope persists because nobody writes it down until the quarterly review.
+
+None of this is complicated. All of it requires someone to own the rhythm. The engagements where this rhythm exists do not have the billing surprise in month nine. The ones where it does not exist always do.
+
+## The question worth asking
+
+If you are on the merchant side of a post-launch engagement, ask your implementation partner a simple question: "What work did your team do last month that was not in our SOW?"
+
+If they can answer precisely, you have a well-governed engagement.
+
+If they hesitate, you have a billing question that is about to surface. Better to find it now than in the third quarter.
\ No newline at end of file