Skip to content

Explain the obvious GCP charges in Feb/Mar/May 2025

Goal / question

Owner sees obvious GCP charges in Feb, Mar & May 2025 — explain why (what they are, and why present / not categorized-or-matched). Ties to the GCP billing reconciliation work (GL6006, MISC DEBIT verdict, evidence-only matching, statement-as-invoice).

Findings (2026-06-13, live data)

Two distinct Google products in those months (Company Card *4687): - *Google CLOUD (= actual GCP) — tiny, UNCATEGORIZED (no GL): 2025-02-09 HK$0.75 · 2025-03-02 HK$0.31 · 2025-05-02 HK$0.31. Real GCP usage charges, micro-amounts → consistent with near-free-tier Cloud Run/Firestore spill (PDF renderer + bank-login-service run scale-to-zero on aote-pms). They're uncategorized because nothing matched/booked them. - Google WORKSPACE (NOT GCP) — already categorized to GL 6000: 2025-02-02 HK$528.12 · 2025-03-02 HK$282 · 2025-05-01 HK$282. Different product (email/Workspace seats), correctly not GCP. - The only GL-6006/6400 entry in those months is 2025-02-04 HK$150 TRANSFER-DEBIT on 6400 (a bank charge, unrelated to GCP). So "the obvious GCP charges" = the three sub-HK$1 Google Cloud card charges, currently uncategorized. Nothing alarming; just un-booked micro-usage. Decision for owner: leave as immaterial, or categorize them (and where — a GCP/IT GL).

Why the auto-matcher didn't book them (2026-06-13)

By design — your own evidence-only policy. The two Google paths differ: - Workspace = pattern-based: an auto-link rule (patterns 'GOOGLE WORKSPACE'/'GSUITE', from GL 6000's autoMatch.keywordPatterns) + File-Archive Workspace invoices → amount+date match → books to GL 6000. (pages/api/workspace-billing/auto-link.ts, lib/googleWorkspace/matcher.ts.) - GCP = evidence-only: the GCP auto-linker REQUIRES a fetched GCP invoice (BigQuery export or a Firestore Cost-Table import). For these micro-charges there's NO GCP invoice for those months → invoice == null → skipped → uncategorized. categorizeWithoutMatch: false (AUTO_MATCH_DEFAULTS, types.ts) means it won't book without invoice evidence — same principle as the Aug/Sep 2025 export blocker (T-016). (pages/api/gcp-billing/auto-link.ts.) So: working as designed. To book them, either import the GCP invoice/Cost-Table for Feb/Mar/May 2025 (then they auto-link), or categorize the 3 micro-charges manually. NOT recommended: flipping categorizeWithoutMatch — you set evidence-only deliberately.

What's actually lacking (2026-06-13, live data — owner was right, evidence DOES exist)

GCP invoices ARE imported: tebs-erl/Expenses/Subscriptions/Google/GCP/invoices holds cloud_console_csv rows for 202501–202606 (all 3 months): 202502 netCost HK$0.31, 202503 HK$0.31, 202505 HK$0.30 — but all with transactionCount: 0 (locked). So the evidence is NOT the gap. The real gaps: 1. Never linked — transactionCount 0 on all three ⇒ the GCP auto-linker hasn't tied a card charge to these invoices. 2. Amount/timing reconciliation — card charges (Feb HK$0.75, Mar 0.31, May 0.31) ≠ console netCost (0.31/0.31/0.30). GCP bills USD→HKD at its own rate and IN ARREARS (a 2025-02-09 card charge is ~Jan usage), so exact-amount (±0.01) matching fails for Feb & May. Only Mar (0.31==0.31) lines up — and even it wasn't linked, i.e. the linker likely hasn't been re-run since the CSV import. FIX: (a) re-run the GCP auto-linker for those months (should catch Mar); (b) the Feb/May FX+arrears gap needs a tolerance band / date-offset / aggregation — same currency theme as T-029b. This is a LINKING + reconciliation gap, not an evidence gap.

Offset analysis — all 15 Google Cloud charges (2026-06-13) — corrects the FX guess

Amounts MATCH EXACTLY; the gap is purely TIMING (arrears), not FX. Pairing each charge to its usage-month GCP invoice: - 11 of 15 charges == their PRIOR-month invoice to ±HK$0.01 (GCP bills the card the exact HKD invoice amount, ~1 month in arrears; charge posts 2–9 days AFTER the usage month closes). e.g. 2026-02-03 $29.86 == 202601 $29.86; 2026-03-03 $6.90 == 202602 $6.90; 2026-05-02 $21.14 == 202604 $21.14; 2025-02-09 $0.75 ≈ 202501 $0.76. - So the "FX mismatch" idea was WRONG — amount is exact; only the ~1-month arrears separates the charge date from the usage month. - OUTLIERS (no matching usage invoice): $100 (2026-05-09), $100 (05-12), $200 (05-17), $499.31 (2026-06-04). Round + no invoice → look like prepaid top-ups / a spend spike, NOT usage bills. These are the ONLY big "offsets" (HK$79–198) and they're mis-pairings. BIGGEST OFFSETS: amount ≤ HK$0.01 for real usage charges (the HK$198 figure is an outlier top-up with no invoice); timing ≈ 1 month arrears (charge 2–9 days after usage month-end). So: amount tolerance is a non-issue (exact). Fix = (a) re-run the GCP linker with a window covering the ~1-month arrears (45-day default already covers it) → links the 11 clean ones; (b) check whether locked:true excludes them from linking; (c) review the 4 outlier top-up/spike charges separately. Not FX, not evidence — un-run linker + arrears window.

Log

  • 2026-06-13 created + investigated. Answered: 3 tiny Google Cloud charges (uncategorized)
  • larger Workspace charges (already GL 6000). Awaiting owner call on categorizing.