Invoiced wallet transactions show as granted instead of purchased in exported data

In an exported dataset (for example a BigQuery mirror of Lago data), you find inbound wallet transactions whose transaction_status is granted yet which have an invoice associated. That combination looks contradictory: granted credits are free top-ups and should not carry an invoice. The cause here was stale exported data. In Lago's source database those rows are purchased, not granted, and the exported copy held an old value that a data refresh corrected.

How to read inbound wallet transaction statuses

An inbound, granted wallet transaction is a free credit top-up and carries no invoice. An inbound, purchased wallet transaction is a paid prepaid top-up, so the customer is issued an invoice for the purchase. So an inbound transaction that has an invoice associated should be classified as a real prepaid purchase, not as free credits. If the export shows granted on a row that has an invoice, treat the export value as suspect rather than the transaction as anomalous.

How to confirm the cause

Compare the status in your exported table against the same transaction in Lago. The query below finds the suspicious rows in an exported dataset:

SELECT
  wt.*,
  i.status AS invoice_status,
  i.payment_status AS invoice_payment_status
FROM wallet_transactions wt
LEFT JOIN invoices i
  ON wt.lago_invoice_id = i.lago_id
WHERE transaction_type = 'inbound'
  AND transaction_status = 'granted'
  AND lago_invoice_id IS NOT NULL

If those same transactions read as purchased in Lago itself, the discrepancy is in the export, not in Lago. This is what happened on this ticket: the source had been purchased the whole time, and the exported value was frozen at an old granted reading.

How to resolve the issue

Contact Lago Support to request a full refresh of the affected table in your data warehouse. A full refresh wipes and rewrites the table, which clears the stale values. The trade-off is that the table is briefly unavailable while it rewrites, so anything reading from it downstream may be interrupted for the duration. On this case the refresh completed in a couple of minutes and resolved the discrepancy.

Why a refresh is needed rather than a fix in Lago

The operations that historically set transaction_status did not always update the row's updated_at timestamp. An incremental export keyed on updated_at would therefore never re-read those untouched rows, leaving an old value in place indefinitely. A full refresh sidesteps that by re-reading every row. This is an implementation detail of how the export pipeline and historical migrations interacted and is subject to change.

This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.