Ad accounts, top-ups, daily and hourly spend
Balance by account type, runway in business days
Status per account: ok, low, critical or undetermined
Top-up request to the client and alert to the team
What it solves
- The top-up is requested while there is still time for the payment to clear.
- The reported balance is what the platform declares, not arithmetic between limit and spend.
- Postpaid accounts show the amount owed, never mixed with balance.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- Meta Ads and Google Ads connected to Nekt, with the accounts table and the activity log
- The account-to-client registry with each client's official accounts
- The payment window agreed with each client (in business days) and the fee on top-ups, if any
What you get
- A current table per client and account with payment model, balance, amount owed and business days until empty
- A daily balance history to see trends and check the alert
- Low and critical balance alerts, with state, for the team and the client
- An AI agent that answers about balance by reading the right field for each account type
Where to activate
Message on the client's channel with balance, the pace of the last 3 days and the estimated date, only when the status changes.
Daily list of accounts in critical and low for the account team, with the collection task opened.
Answers 'what is the balance' by reading the right field for prepaid and postpaid.
Few sources and closed rules. What needs care is reading the balance from the text Meta returns and keeping the business-day calendar. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
Meta's accounts table carries balance, spend_cap and amount_spent, but none of them is the balance of a prepaid account: the available balance only comes written inside a payment method text. On a postpaid account, balance is what is owed. Google stores budget limit and consumption as text in micros. Whoever computes balance as limit minus spend, or counts calendar days until empty, sends the top-up request on a Friday afternoon and the account stops on Saturday.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Classify each account by is_prepay_account. On prepaid, the question is available balance. On postpaid, it is the amount owed, stored as a positive number and shown with a negative sign only in presentation. Never add a prepaid balance to a postpaid amount owed.
spend_cap - amount_spent, or the prepaid account's balance field.On a prepaid account, read the value from the 'Saldo disponível (...)' (available balance) text in funding_source_details.display_string. The balance field is not the prepaid balance, and spend_cap - amount_spent is not either: spend_cap is a spending limit and amount_spent is the lifetime spend of the account. If the text cannot be parsed safely (another currency, another language), the balance is null, never zero. Keep the raw balance under a neutral name for auditing.
Meta's balance, amount_spent and spend_cap come in the currency's smallest unit: divide by 100. In Google, adjusted_spending_limit_micros and amount_served_micros come as text in micros: cast to number and divide by 1,000,000. Each account has its own currency; never sum different currencies.
Use the account_budget row with status APPROVED and the most recent approved_start_date_time for the account. Balance = adjusted_spending_limit_micros - amount_served_micros, in reais. The connector does not bring individual top-ups: the budget is the approved total and the accumulated consumption.
spend with no starting point.When the platform does not expose the balance, start from a reference balance checked on screen at a known moment. Current balance = reference + top-ups confirmed after it (event_type funding_event_successful in the activity log) - spend after it (hourly insights, starting from the first full hour after the reference). Reset the reference whenever the value diverges from the screen.
If a Pix top-up carries a tax (for example, 12.15%), the net balance is the amount paid x (1 - fee). Compare the daily budget configured in the campaigns with the net balance, not with the amount the client transferred.
spend and counting calendar days.Average spend = mean of the last 3 complete days (today is left out because the day is only half over). Days until empty = balance / average spend. Convert to business days, without weekends and holidays, because the client pays on business days. With no valid average spend, the status is undetermined, not infinite.
Critical at 5 business days or fewer, the minimum to request, approve, pay and clear the top-up; low at 6 to 7 business days; ok above that. The window belongs to each client and lives in that client's context. The message to the client and the internal alert are different texts.
A source's accounts table lists everything the credential can see in the Business Manager. Filter by the official account_id from the registry. The source that brought the financial data may sit in another client's layer: never infer the account's owner from the source layer. Sum balances of different accounts only within the same snapshot and currency.
The current table has one row per client and account and says when it was generated; it does not answer yesterday's balance. In parallel, append a daily history. The alert stores the last status sent per account and only fires again when the status changes or worsens, with a send log.
Which field answers the balance
By platform and account type.
Definitions
spend over the last 3 complete days / 3, per accountspendspend (bands adjustable per client)Pitfalls that already happened
Balance computed as spending limit minus lifetime spend goes negative on accounts with no limit (spend_cap zero) and, on the others, has nothing to do with the available credit.
Read the balance Meta declares; limit and lifetime spend do not make a balance.
On prepaid accounts, balance comes as zero and the balance is only written in the payment method text. A monitor that reads balance flags every prepaid account as empty.
Extract the value from the available balance text and leave it null when that fails.
Runway was counted in calendar days. The top-up request went out with two days to spare, which fell on the weekend.
Count in business days, with the client's payment window.
The budget configured in the campaigns was planned with the full Pix amount, but the top-up arrived net of the fee and the money ran out before month end.
Compare the configured budget with the net balance.
The spend average included the half-finished current day and underestimated the pace, pushing the run-out date forward.
Use only complete days in the average.
With the reference balance checked in the middle of an hour, that whole hour's spend enters the ledger and the balance ends up below what the screen shows.
Count spend from the first full hour after the reference.
Acceptance test
The case is done when every item passes.
- For each prepaid account, the available balance in the table equals what Ads Manager shows at snapshot time.
- No prepaid account has a balance computed from spend_cap or amount_spent.
- The current table has one row per client and official account, and no account outside the registry.
- Business days until empty is never below zero and is undetermined when there are not 3 complete days of spend.
- Each account gets at most one alert per status change.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Ad account balances - Prepaid account (is_prepay_account true): 'balance' = value from the 'Saldo disponível' (available balance) text in funding_source_details.display_string. If it is not available, say the balance was not obtained. Never use balance, spend_cap or amount_spent as the balance. - Postpaid account: balance / 100 is the amount owed. Show it with a negative sign only if asked for 'positive and negative balance'. - Meta values in cents; Google in micros. Do not sum different currencies. - Google: balance = adjusted_spending_limit_micros - amount_served_micros of the most recent APPROVED budget. - Business days until empty = balance / average spend of the last 3 complete days, counted in business days. - Status: critical up to 5 business days, low from 6 to 7, ok above. No valid average: undetermined. - The current table does not answer past balances. Use the daily history. - Only accounts in each client's registry. The source layer does not define the account's owner. Client exceptions: - <client>: Pix top-up with a <x>% fee; net balance = paid x (1 - fee). - <client>: payment window of <n> business days; critical below <n>.
Build the "Ad account balances" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/agencias/saldo-contas-de-anuncio.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Amount to reach month end = average spend x days left - balance, with the top-up fee already added.
Compare average spend with the media plan's daily budget to know whether the top-up covers what was planned.
Alert when the amount owed approaches the billing threshold or when the account changes status after a payment failure.