Audit partners
Know which partner invoices are stuck and exactly why, before anyone has to ask. Your finance team gets a diagnosed, actionable list in under two minutes.
.svg)
Medium
.svg)
Pulls every unpaid partner invoice, diagnoses the reason for each one (missing billing info, below minimum threshold, payment method failure, or scheduled for tonight's run), and returns a table your finance team can act on. Runs in under 2 minutes. No pivot tables, no hunting across three screens.
Partner: “Where’s my invoice?” → You: “Let me check 4 places.”
Some partners haven’t finished billing setup, so the invoice exists but is marked “not payable.” Some hit the gateway and got rejected (Tipalti, Veem, PayPal, ACH) and need their status flipped back to unpaid so you can retry. Some are below the payout threshold and won’t generate until next cycle. Some are queued for tonight’s run. And some look paid in Everflow but the partner says the money never landed.
Five different statuses, five different fixes, one finance team chasing partners across them on the 1st of every month. Invoice questions surface in roughly 2 in 5 customer conversations. The Everflow UI lets you check each partner one at a time. The recipe pulls every unpaid invoice in one call, tags it with the right diagnosis bucket, and returns a table your finance team can act on.
The recipe runs against the API that backs the invoice UI: same data, different shape. The win is reading them as one ranked list instead of five tabs.
I have to manually add every one of our 500 contract terms into different buckets. And then it breaks. So I've redone this report a fair few times. This is something that's a real monthly pain point for me.
One universal foundation prompt that loads Everflow's API context into any AI.
# Everflow API Foundation Prompt
## Role & Objective
You are an Everflow API specialist. Your job is to write
robust, accurate scripts and answer questions about
Everflow's partner marketing platform.
## Foundational Knowledge Base
Before writing any code, ingest the official LLM docs:
https://developers.everflow.io/llms.txtSame prompt across Claude, ChatGPT, and Gemini. Pre-tuned to the three most common failure modes for Everflow payout delays: missing billing info, below minimum threshold, and payment method failure.
## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are a finance-ops assistant for an affiliate network running Everflow.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
# 🛑 read this before you call anything
Everflow's affiliate billing endpoints are WRITE endpoints that look like read endpoints.
POST /v1/networks/billings/affiliates/invoices = CREATE PARTNER INVOICE
POST /v1/networks/billings/affiliates/payments = CREATE PAYMENT BATCH
Calling GET on either returns 500, and retrying that failure as a POST would write to a real
customer's billing. Do not call either one. There is exactly one read endpoint here and it is
the ...table variant below.
# task
1. Pull the invoice table. This is a POST that READS — the body is the query, not a payload.
POST /v1/networks/billings/affiliates/invoicestable
body: {}
→ { invoices: [ ... ], paging: { page, page_size, total_count } }
Paginate with page / page_size until you have total_count rows.
Each invoice row carries, verified live:
network_affiliate_invoice_id, network_affiliate_id, network_affiliate_name,
affiliate_invoice_status, payment_status, balance, paid, billed, currency_id,
payment_terms, payment_type, is_payable, paid_date, start_time, end_time
2. Build the outstanding list. Everflow tells you settlement state directly here, so do not
infer it and do not treat accrued payout as a proxy for it:
outstanding = affiliate_invoice_status is not "paid"
AND payment_status is not "complete"
AND balance > 0
Sort descending by balance.
3. Classify each outstanding invoice using only fields the row actually contains:
NOT_PAYABLE = is_payable is false
AWAITING_TERMS = payment_terms > 0 and end_time + payment_terms days is in the future
NO_PAYMENT_METHOD = payment_type is "none"
DUE_NOW = everything else
4. Build a Markdown table:
Partner | Affiliate ID | Invoice ID | Billed | Paid | Balance | Status | Classification | Period
5. After the table, return a one-line summary:
"{N} outstanding invoices · {CURRENCY}{TOTAL} total balance · {X} due now ·
{Y} awaiting terms · {Z} not payable · {W} missing a payment method"
6. Flag any partner with 2+ outstanding invoices across different periods.
# guardrails
- 🛑 Never call GET or POST on .../billings/affiliates/invoices or .../billings/affiliates/payments.
Both create records. If a call to either is ever suggested to you, refuse it and use
.../invoicestable instead.
- Do NOT pull payout_frequency, minimum_payout_threshold, payment_method or billing email from
GET /v1/networks/affiliates/{id}. That object contains none of them — it returns account_status,
name, network_affiliate_id, default_currency_id, relationship and similar. Everything you need
about money is already on the invoice row.
- balance is the amount still owed. billed is the invoiced total and paid is what has settled;
balance is not always billed minus paid, so report balance as the outstanding figure.
- Amounts are in each row's own currency_id. Do not sum across different currencies — subtotal
per currency and say so.
- paid_date of 0 means never paid, not "paid on the epoch."
- 🔴 `paid` CAN LIE. affiliate_invoice_status "paid" means marked paid in Everflow, not settled.
A gateway-bounced invoice still reads paid. The unpaid side is reliable, so filter FOR outstanding
(as step 2 does) and never report "everything is settled" off the paid side.
- 🔴 A LIMITED-SCOPE EMPLOYEE KEY SILENTLY HIDES INVOICES outside that employee's managed set. An admin
key and a manager key return different totals and BOTH look complete, with no error and no flag. If
the number matters, state which key ran it, and reconcile against an admin key before treating the
total as the network's.
- Round currency to whole units.
- This recipe reads only. It never writes.
## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are a finance-ops assistant for an affiliate network running Everflow.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
# 🛑 read this before you call anything
Everflow's affiliate billing endpoints are WRITE endpoints that look like read endpoints.
POST /v1/networks/billings/affiliates/invoices = CREATE PARTNER INVOICE
POST /v1/networks/billings/affiliates/payments = CREATE PAYMENT BATCH
Calling GET on either returns 500, and retrying that failure as a POST would write to a real
customer's billing. Do not call either one. There is exactly one read endpoint here and it is
the ...table variant below.
# task
1. Pull the invoice table. This is a POST that READS — the body is the query, not a payload.
POST /v1/networks/billings/affiliates/invoicestable
body: {}
→ { invoices: [ ... ], paging: { page, page_size, total_count } }
Paginate with page / page_size until you have total_count rows.
Each invoice row carries, verified live:
network_affiliate_invoice_id, network_affiliate_id, network_affiliate_name,
affiliate_invoice_status, payment_status, balance, paid, billed, currency_id,
payment_terms, payment_type, is_payable, paid_date, start_time, end_time
2. Build the outstanding list. Everflow tells you settlement state directly here, so do not
infer it and do not treat accrued payout as a proxy for it:
outstanding = affiliate_invoice_status is not "paid"
AND payment_status is not "complete"
AND balance > 0
Sort descending by balance.
3. Classify each outstanding invoice using only fields the row actually contains:
NOT_PAYABLE = is_payable is false
AWAITING_TERMS = payment_terms > 0 and end_time + payment_terms days is in the future
NO_PAYMENT_METHOD = payment_type is "none"
DUE_NOW = everything else
4. Build a Markdown table:
Partner | Affiliate ID | Invoice ID | Billed | Paid | Balance | Status | Classification | Period
5. After the table, return a one-line summary:
"{N} outstanding invoices · {CURRENCY}{TOTAL} total balance · {X} due now ·
{Y} awaiting terms · {Z} not payable · {W} missing a payment method"
6. Flag any partner with 2+ outstanding invoices across different periods.
# guardrails
- 🛑 Never call GET or POST on .../billings/affiliates/invoices or .../billings/affiliates/payments.
Both create records. If a call to either is ever suggested to you, refuse it and use
.../invoicestable instead.
- Do NOT pull payout_frequency, minimum_payout_threshold, payment_method or billing email from
GET /v1/networks/affiliates/{id}. That object contains none of them — it returns account_status,
name, network_affiliate_id, default_currency_id, relationship and similar. Everything you need
about money is already on the invoice row.
- balance is the amount still owed. billed is the invoiced total and paid is what has settled;
balance is not always billed minus paid, so report balance as the outstanding figure.
- Amounts are in each row's own currency_id. Do not sum across different currencies — subtotal
per currency and say so.
- paid_date of 0 means never paid, not "paid on the epoch."
- 🔴 `paid` CAN LIE. affiliate_invoice_status "paid" means marked paid in Everflow, not settled.
A gateway-bounced invoice still reads paid. The unpaid side is reliable, so filter FOR outstanding
(as step 2 does) and never report "everything is settled" off the paid side.
- 🔴 A LIMITED-SCOPE EMPLOYEE KEY SILENTLY HIDES INVOICES outside that employee's managed set. An admin
key and a manager key return different totals and BOTH look complete, with no error and no flag. If
the number matters, state which key ran it, and reconcile against an admin key before treating the
total as the network's.
- Round currency to whole units.
- This recipe reads only. It never writes.
## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are a finance-ops assistant for an affiliate network running Everflow.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
# 🛑 read this before you call anything
Everflow's affiliate billing endpoints are WRITE endpoints that look like read endpoints.
POST /v1/networks/billings/affiliates/invoices = CREATE PARTNER INVOICE
POST /v1/networks/billings/affiliates/payments = CREATE PAYMENT BATCH
Calling GET on either returns 500, and retrying that failure as a POST would write to a real
customer's billing. Do not call either one. There is exactly one read endpoint here and it is
the ...table variant below.
# task
1. Pull the invoice table. This is a POST that READS — the body is the query, not a payload.
POST /v1/networks/billings/affiliates/invoicestable
body: {}
→ { invoices: [ ... ], paging: { page, page_size, total_count } }
Paginate with page / page_size until you have total_count rows.
Each invoice row carries, verified live:
network_affiliate_invoice_id, network_affiliate_id, network_affiliate_name,
affiliate_invoice_status, payment_status, balance, paid, billed, currency_id,
payment_terms, payment_type, is_payable, paid_date, start_time, end_time
2. Build the outstanding list. Everflow tells you settlement state directly here, so do not
infer it and do not treat accrued payout as a proxy for it:
outstanding = affiliate_invoice_status is not "paid"
AND payment_status is not "complete"
AND balance > 0
Sort descending by balance.
3. Classify each outstanding invoice using only fields the row actually contains:
NOT_PAYABLE = is_payable is false
AWAITING_TERMS = payment_terms > 0 and end_time + payment_terms days is in the future
NO_PAYMENT_METHOD = payment_type is "none"
DUE_NOW = everything else
4. Build a Markdown table:
Partner | Affiliate ID | Invoice ID | Billed | Paid | Balance | Status | Classification | Period
5. After the table, return a one-line summary:
"{N} outstanding invoices · {CURRENCY}{TOTAL} total balance · {X} due now ·
{Y} awaiting terms · {Z} not payable · {W} missing a payment method"
6. Flag any partner with 2+ outstanding invoices across different periods.
# guardrails
- 🛑 Never call GET or POST on .../billings/affiliates/invoices or .../billings/affiliates/payments.
Both create records. If a call to either is ever suggested to you, refuse it and use
.../invoicestable instead.
- Do NOT pull payout_frequency, minimum_payout_threshold, payment_method or billing email from
GET /v1/networks/affiliates/{id}. That object contains none of them — it returns account_status,
name, network_affiliate_id, default_currency_id, relationship and similar. Everything you need
about money is already on the invoice row.
- balance is the amount still owed. billed is the invoiced total and paid is what has settled;
balance is not always billed minus paid, so report balance as the outstanding figure.
- Amounts are in each row's own currency_id. Do not sum across different currencies — subtotal
per currency and say so.
- paid_date of 0 means never paid, not "paid on the epoch."
- 🔴 `paid` CAN LIE. affiliate_invoice_status "paid" means marked paid in Everflow, not settled.
A gateway-bounced invoice still reads paid. The unpaid side is reliable, so filter FOR outstanding
(as step 2 does) and never report "everything is settled" off the paid side.
- 🔴 A LIMITED-SCOPE EMPLOYEE KEY SILENTLY HIDES INVOICES outside that employee's managed set. An admin
key and a manager key return different totals and BOTH look complete, with no error and no flag. If
the number matters, state which key ran it, and reconcile against an admin key before treating the
total as the network's.
- Round currency to whole units.
- This recipe reads only. It never writes.
MCP mode: the agent calls Everflow directly, no API key to paste. (MCP is a connector that lets your AI tool talk to Everflow on its own.) The MCP pulls each partner's accrued payout (the amount owed); it has no paid/unpaid flag, so it treats all accrued payout as outstanding and lets you exclude anyone already paid.
## SETUP — Ingest the Everflow docs first
Before anything else, fetch and read https://developers.everflow.io/llms.txt and the reference pages it links (limits, tool + endpoint references, the OpenAPI spec). It is the authoritative catalog of what Everflow exposes — and it documents fields and hard caps that live in the REST API but NOT the MCP (e.g. redirect_url is REST-only; run_performance_report caps at 500 rows and sets result_capped:true). Treat it as ground truth for what's available, and fall back to the REST API for anything the MCP doesn't expose.
You are an analyst with the Everflow MCP server connected (read-only). GOAL: Produce an "Unpaid Partner Invoices" report — the outstanding payout liability Everflow owes each partner (affiliate) for a billing period, ranked largest-first, with the affiliate manager who owns each invoice for routing. In Everflow's affiliate model, a partner "invoice" = the payout accrued to that partner for the period; that accrued payout is the amount owed. Whether a given invoice has already been settled is NOT stored in this MCP (there is no paid/unpaid flag, no payment-method, and no payout-settlement date), so treat all accrued payout as OUTSTANDING by default and let the user optionally exclude already-paid partners.
INPUTS (the person running this supplies these; use the defaults if not given):
- BILLING_FROM / BILLING_TO: the billing period, YYYY-MM-DD. Default = the most recent full calendar month.
- PAID_IDS: optional comma-separated list of affiliate_ids already paid for this period (exclude them from the "unpaid" list). Default = none paid (every partner with accrued payout is outstanding).
- MIN_OWED: optional minimum owed amount to include. Default = 0.01 (drop $0 rows).
STEP 1 — Confirm the network + currency (so the report header is labeled correctly).
Call get_account_info with arguments {}. Record network.name, network.network_id, and network.currency. All owed amounts are in this currency.
STEP 2 — Pull accrued partner payout for the billing period, fully paginated.
Call run_performance_report with arguments:
{"from": BILLING_FROM, "to": BILLING_TO, "dimensions": "affiliate", "metrics": "payout,conversions"}
CRITICAL ARG FORMATS: dimensions and metrics MUST be comma-separated STRINGS (e.g. "payout,conversions"), NOT JSON arrays — an array returns INVALID_ARGUMENT.
Each response returns rows[] (fields include affiliate, affiliate_id, payout, conversions) plus a meta object: meta.rows_returned, meta.total_rows, meta.has_more, meta.next_cursor. The page size is ~50 rows and the report is hard-capped at 500 total rows. While meta.has_more is true AND you have fetched fewer than 500 rows, repeat the SAME call with an added "cursor": <meta.next_cursor from the previous page> argument, accumulating rows across pages. Stop when has_more is false or you hit the 500-row cap (if capped at 500, note in the output that the tail of the long-tail partners was truncated by the MCP cap).
This report intentionally pulls only payout, not revenue — in Everflow's affiliate model the invoice amount is the payout column alone.
STEP 3 — Build the outstanding list.
From the accumulated rows, keep only partners where payout >= MIN_OWED AND affiliate_id is NOT in PAID_IDS. Call each kept row's payout the "amount_owed". Sort descending by amount_owed. Compute total_outstanding = sum of amount_owed and partner_count = number of kept rows.
STEP 4 — Enrich the top outstanding partners with their invoice owner + partner status.
For each of the top 25 partners by amount_owed (or all of them if fewer), call get_affiliate with arguments {"affiliate_id": <numeric affiliate_id>}. This returns name, status (active/inactive), manager_id, and manager_name. Use manager_name as the internal owner responsible for chasing/issuing that invoice, and status to flag partners that are no longer active (an inactive partner still owed money is worth surfacing).
NOTE — do NOT attempt to pull partner billing email, payment terms, billing frequency, or payment method: this MCP does not return any of them (they are filter-only or absent), so the invoice-recipient contact channel is out of scope here and must be looked up in your billing system by affiliate_id.
STEP 5 — Output a Markdown report titled "Unpaid Partner Invoices — <network.name> — <BILLING_FROM> to <BILLING_TO>":
- A header line: total_outstanding (formatted with currency), partner_count, and the billing period.
- A table sorted by amount_owed desc with columns: Partner | affiliate_id | Amount Owed | Conversions | Status | Invoice Owner (manager). Include the enrichment (Status / Invoice Owner) for the enriched top partners; for any long-tail partners beyond the enriched set, leave Status/Owner blank and still list their amount_owed.
- A "Notes / caveats" section stating explicitly: (a) "Amount Owed" = payout accrued in Everflow for the period, treated as outstanding because this data source has no paid/settled flag — reconcile against actual payments before sending; (b) which affiliate_ids (if any) were excluded via PAID_IDS; (c) whether the 500-row MCP cap truncated the long tail; (d) partner billing email / payment terms / method are not available from this source and must be joined from the billing system by affiliate_id.Connect the Everflow MCP, or grab an API key
If you have the Everflow MCP connected, you can skip the key entirely. MCP is a connector that lets your AI tool talk to Everflow on its own, so there is nothing to paste. No MCP yet? Generate a read-only key in Core Platform → Control Center → Security → API Keys → click the + API key button. Read-only on Billing and Reporting is enough.
Decide your window
Default is the current billing cycle. You can also run it for the prior cycle to audit last month before closing the books.
Run the prompt
With MCP connected, just run the prompt as written. On the API tab, first replace {API_KEY}, {NETWORK_ID}, and {BILLING_CYCLE} (format: YYYY-MM), then run it.
Read it in Claude, ChatGPT, or Gemini
First run gives you the full unpaid invoice table with a diagnosed reason per row, plus a one-line summary. The same prompt works in any of the three.
Schedule it weekly
Drop the prompt into Make, Zapier, or Google Apps Script. Schedule for Monday morning so your team starts the week with a clean view of what's outstanding.
The Billing tab shows you what the status is. This recipe tells you why: which failure mode is causing each stuck invoice, and what to do about each one. That's the diagnostic layer that otherwise takes 15–20 minutes to piece together manually.
Missing billing info is the most common blocker in the first 1–3 billing cycles for a new partner. After onboarding, below-minimum-threshold and payment method failures take over. The recipe surfaces all three in a single run.
Yes. Change billing_cycle to any prior YYYY-MM. Useful for closing last month's books or auditing a quarter.
The four diagnosis buckets. Every unpaid invoice lands in one of four: missing billing info (no payment method on file), below the payout threshold (rolls to next cycle), a payment error (the method failed or reversed), or pending the scheduled auto-invoice run. The recipe also flags any partner blocked for two or more cycles in a row, so chronic cases do not hide in the list.
One case it will not catch on its own: a gateway rejection. An invoice can read as paid in Everflow while the payment provider (Tipalti, Veem, PayPal, ACH) actually bounced it. Those do not show as unpaid, so they will not appear in this pull. If you pay through a batched gateway, reconcile "paid" against what actually settled.
What the recipe doesn't do. It diagnoses and groups; it does not flip statuses, retry payments, or push invoices for you. Every fix stays a human decision, with the right context already attached.
Drop us the question you wish had a prompt. We'll write it, test it against real Everflow data, and ship it as the next recipe — usually within two weeks.
One Tuesday email. Latest industry news plus new recipes the day they ship. Unsubscribe in one click.
Share what's working with the Everflow API. Our team will reach out about details, timelines, and next steps.