Прогноз денежного потока на 90 дней

Строит прогноз денег на 30, 60 и 90 дней с диапазоном неопределённости и называет риски, например нехватку на зарплату.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Строит прогноз денег на 30, 60 и 90 дней с диапазоном неопределённости и называет риски, например нехватку на зарплату.
Когда брать: Когда нужно понять, хватит ли денег на зарплату и обязательные платежи в ближайшие месяцы.
Когда не брать: Если нет ни данных учёта и платёжных сервисов, ни таблицы доходов и расходов.
Пример запроса: Хватит ли мне денег на зарплату в следующем месяце? Построй прогноз на 90 дней.
Работает лучше с: бухгалтерская система (QuickBooks, Xero, NetSuite, MYOB, Zoho Books), PayPal, Square или Stripe, Shopify, Gusto, Ramp

Входит в плагин small-business. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку cash-flow-snapshot в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: cash-flow-snapshot
description: >
  Читает дебиторскую и кредиторскую задолженность (AR/AP), историю сроков
  поступления денег и известные постоянные расходы из учётной системы (MYOB,
  NetSuite, QuickBooks, Xero или Zoho Books) либо из PayPal, Square или Stripe —
  или из загруженного CSV — и строит прогноз денежного потока на 30/60/90
  дней с доверительными коридорами по процентному разбросу и названными
  флагами рисков. Выдаёт сводку в чате и XLSX для скачивания. Используй, когда
  пользователь просит «спрогнозируй мой денежный поток», «хватит ли мне на
  зарплату», упоминает «запас хода (runway)» или говорит «кассовый разрыв».
  Когда живого коннектора нет, переходит на загрузку CSV.
compatibility: "Requires one or more of: a ledger MCP (MYOB, NetSuite, QuickBooks, Xero, Zoho Books), PayPal MCP, Shopify MCP, Square MCP, Stripe MCP, file upload (CSV fallback). Output uses xlsx skill."
allowed-tools: Read, WebFetch
---

Срез денежного потока

Строит прогноз денежного потока на 30/60/90 дней с доверительными коридорами по процентному разбросу и названными флагами рисков. Выдаёт результат из двух частей: краткую сводку в чате и рабочую книгу XLSX для скачивания.

Быстрый старт

«Хватит ли мне денег на зарплату в следующем месяце?»

Claude достаёт текущий банковский остаток, AR/AP и постоянные расходы из подключённых источников, рассчитывает ожидаемые поступления и выплаты по окнам в 30, 60 и 90 дней, применяет доверительные коридоры по разбросу сроков оплаты каждого клиента и называет конкретные риски.

Рабочий процесс

Шаг 1. Определи доступные источники данных

Проверь, какие коннекторы работают. Бери данные из каждого, который работает, одной пачкой:

Учётная система — MYOB, NetSuite, QuickBooks, Xero или Zoho Books, какая подключена — для возрастного анализа AR, AP, постоянных расходов и денежного остатка. Учётные системы равноправны (../../shared/connector-neutrality.md); если подключены две, спроси, какая из них источник истины, и бери итоги только из неё
PayPal — история транзакций и сроки расчётов
Square — история продаж и выплат
Stripe — история списаний и выплат
Shopify — заказы (list-orders) как поступления, плюс сроки выплат. Одного Shopify достаточно, чтобы начать: для торгового бизнеса это часто самое крупное поступление. Чтение выплат может не получиться, если права коннектора не включают Shopify Payments — тогда спроси у владельца график выплат и моделируй по нему; никогда не выводи задержку из догадок (reference/v2_sources.md)
Загрузка CSV — когда ни один коннектор не подключён

Если нет ни живого коннектора, ни приложенного файла, попроси пользователя подключить источник или загрузить CSV (табличные данные о доходах и расходах в любом разумном формате). Отметь в результате, какие источники использованы: это влияет на ширину доверительного коридора.

Всегда определяй начальный остаток денег — «хватит ли на зарплату» это вопрос про остаток, а не про чистое изменение. Достань его на шаге 2 или спроси: «Сколько сейчас на счёте компании и на какую дату?» Никогда не предполагай остаток. Если никто не знает, озаглавь результат «нет начального остатка — только чистое изменение» и убери деньги на руках из флагов рисков.

Шаг 2. Достань данные

Из учётной системы:

Баланс: банковские и кассовые остатки с датой, на которую они посчитаны, — начальный остаток (в MYOB их нет; см. reference/v2_sources.md)
Отчёт возрастного анализа AR: имя клиента, сумма инвойса, дата инвойса, срок оплаты, дни просрочки
AP: имя поставщика, сумма к оплате, срок оплаты
Повторяющиеся постоянные расходы: аренда, зарплата, подписки (ищи повторяющиеся транзакции)

Из Gusto, если подключён:

Дата и ожидаемая сумма следующей выплаты зарплаты и обычная периодичность выплат — настоящие цифры для самого крупного постоянного расхода вместо вывода зарплаты из повторяющихся транзакций. Когда Gusto и учётная система расходятся по зарплате, доверяй Gusto в части срока и суммы и скажи об этом в результате

Из PayPal / Stripe / Square:

История расчётов: дата транзакции, сумма, дата расчёта
Используй задержку расчёта (дата транзакции → дата выплаты), чтобы вычислить среднюю задержку оплаты и её разброс по каждому источнику

Из загруженного CSV:

Разбери как табличные данные о доходах и расходах
Обязательные столбцы (названия могут быть любыми): дата, сумма, тип (доход или расход), описание
Если столбцы неоднозначны, покажи строку заголовков и попроси пользователя подтвердить соответствие

Шаг 3. Посчитай историческую динамику оплат

Для каждого клиента из AR (или источника дохода из CSV) вычисли:

Среднюю задержку оплаты — среднее число дней от даты инвойса/транзакции до поступления
Разброс оплаты — стандартное отклонение задержки оплаты за последние 6–12 платежей
Разброс задаёт ширину доверительного коридора (см. шаг 4)

Если по клиенту меньше 3 платежей, возьми среднее по всей выборке как точечную оценку и примени по умолчанию коридор ±30%. Когда работаешь по CSV с достаточной историей (≥3 платежей на источник), считай коридор по фактическому разбросу оплаты — не принимай ±30%.

Шаг 4. Построй прогноз на 30/60/90 дней

Построй три временных окна: 0–30 дней, 31–60 дней, 61–90 дней.

Для каждого окна вычисли:

Строка	Метод
Ожидаемые поступления	AR к оплате в окне с поправкой на среднюю задержку оплаты
Ожидаемые выплаты	AP к оплате в окне + постоянные расходы, попадающие в окно
Чистая денежная позиция	Поступления − Выплаты
Доверительный коридор	± средневзвешенный разброс оплаты в % от ожидаемых поступлений

Формула доверительного коридора:

band_pct = weighted_avg_stddev_days / avg_payment_lag_days
low  = net_cash × (1 − band_pct)
high = net_cash × (1 + band_pct)

Округляй band_pct до одного знака после запятой. Ограничь ±50% — более высокий разброс означает, что данных слишком мало для моделирования; отметь это флагом (см. шаг 5).

Шаг 5. Назови риски флагами

Просмотри условия, которые уводят нижнюю оценку в минус или создают нехватку ликвидности. По каждому найденному риску составь однострочный флаг:

Риск позднего плательщика: «Клиент X обычно платит с опозданием на 18 дней; из-за этого его инвойс на 8 400 USD выпадает из 30-дневного окна и приходит на 48-й день».
Нехватка на зарплату: «Зарплата (22 000 USD) уходит 15 апреля. Начальный остаток 31 000 USD на 1 апреля плюс поступления минус выплаты дают нижнюю оценку денег на руках 14 апреля в 19 200 USD. Риск нехватки: 2 800 USD». Нужен остаток с указанным источником.
Предупреждение о нехватке данных: «По клиенту Y в истории только 2 платежа — доверительный коридор принят по умолчанию ±30%».
Предупреждение об отсутствии коннектора: «Расчёт идёт только по данным CSV — нет данных о кредиторской задолженности и повторяющихся расходах в реальном времени. Доверительные коридоры шире обычного».

Ограничься пятью главными рисками по тяжести (сначала с наибольшей суммой в долларах).

Шаг 6. Выдай результаты

Сводка в чате (всегда). Для прогноза используй markdown-таблицу, а не блок кода: интерфейс чата отрисовывает markdown-таблицы, а блок кода выглядит как сырой моноширинный текст. Форма:

Строка заголовка: Срез денежного потока — <диапазон дат>
Источники: <использованные коннекторы>
Начальный остаток: AUD X,XXX на <дата> (или: нет данных — только чистое изменение)

Затем прогноз markdown-таблицей, суммы с кодом валюты бизнеса (../../shared/currency-and-locale.md), а не с голым символом:

Окно	Ожидаемо	Низкая оценка	Высокая оценка
Чистый итог за 30 дней	AUD X,XXX	AUD X,XXX	AUD X,XXX
Чистый итог за 60 дней	AUD X,XXX	AUD X,XXX	AUD X,XXX
Чистый итог за 90 дней	AUD X,XXX	AUD X,XXX	AUD X,XXX

Затем риски коротким списком под строкой «⚠ Отмечено рисков: <число>».

Рабочая книга XLSX (всегда): сначала прочитай xlsx/SKILL.md, затем создай три листа:

Сводка — таблица прогноза на 30/60/90 дней с доверительными коридорами. Под строкой каждого окна разверни вложенные строки с отдельными транзакциями, из которых складываются его поступления (зелёным) и выплаты (красным). Так оценки можно проверить, не покидая листа «Сводка».

Детали — все транзакции, сгруппированные по окнам и отсортированные по дате внутри группы. Добавь столбец нарастающего чистого итога (накопленные поступления минус выплаты внутри окна) и итоговую строку внизу каждого окна: всего поступлений, всего выплат и чистый итог. Прошедшие транзакции приглуши серым в отдельном разделе внизу для справки. Следи, чтобы у всех трёх окон были строки, даже если одно пустое, — покажи строку-заглушку «Нет транзакций в этом окне».

Риски — отмеченные риски с суммой в долларах и затронутым окном.

Сохрани как cash-flow-snapshot-[YYYY-MM-DD].xlsx.

Страница прогноза (всегда, рядом со сводкой в чате — а не вместо неё), в формате, который владелец сохранил как предпочтительный; никогда не делай по умолчанию markdown-файл. Проверь Output preference в блоке ## Business context (правило общего руководства по стилю, ../../shared/artifact-style.md):

Визуальный артефакт (по умолчанию): оформи полный прогноз как HTML-страницу в фирменном стиле. Чистые итоги на 30/60/90 дней — плитки показателей, в поясняющей строке каждой плитки — доверительный диапазон; детали транзакций — таблица с суммами, выровненными по правому краю цифрами одинаковой ширины (tabular-nums); каждый флаг риска несёт плашку статуса — критично для прогнозируемой нехватки, внимание для флагов позднего плательщика и нехватки данных; источники и начальный остаток лежат в небольшой панели в шапке.
Предпочтение docx / md / notion / canva: выдай то же содержимое в этой форме — файл DOCX или markdown, страницу Notion, созданную через коннектор (с названным местом назначения, ничего не перезаписывая), или документ Canva Doc, созданный через коннектор Canva (новый дизайн при каждом прогоне, с датой в названии; таблицы превращаются в списки); если Notion или Canva не подключены, вернись к визуальному артефакту и скажи, что причина в этом. XLSX всё равно идёт в комплекте.
Лучше всего для скилла: визуальный артефакт — прогноз читают с одного взгляда и часто пересчитывают.

После прогона

Одна строка о том, что произошло: прогноз построен, риски названы. Затем предложи единственный самый уместный следующий шаг и не больше двух других рядом:

Если отмечена нехватка на зарплату: «хватит ли мне на зарплату» запускает /plan-payroll.
«Кто мне должен деньги?» запускает invoice-chase, чтобы приблизить поступления.
«Закрой месяц» запускает /close-month, чтобы следующий прогноз шёл по чистому учёту.

Не больше трёх предложений, и никогда не повторяй предложение, от которого владелец отказался в этой сессии.

Шлагбаумы согласования

Этот скилл только читает — шлагбаума согласования перед созданием прогноза нет.

После выдачи напомни пользователю:

«Этот прогноз основан на [перечисленные источники]. Он не заменяет бухгалтерскую консультацию — проверьте с вашим бухгалтером, прежде чем принимать финансовые решения».

Другие источники и расписание

Полное соответствие смотри в reference/v2_sources.md:

Shopify — сроки поступлений платежей, что для торгового бизнеса часто самое крупное единичное поступление, и расчёт идёт с задержкой, которую стоит моделировать
NetSuite — учётная система-источник истины, распространённая на крупном краю сегмента: AR, AP, постоянные расходы и денежный остаток через отчёты и SuiteQL
Xero — учётная система-источник истины: возрастной анализ дебиторской задолженности, счета к оплате, банковские остатки, а также валюта организации и финансовый год
Ramp — расходы по картам, ещё не попавшие в учёт, что чаще всего и делает прогноз тихо оптимистичным
Остатки Ramp — реальные остатки на бизнес- и казначейских счетах с историей. Когда владелец обслуживается в Ramp, это начальный остаток с указанным источником, а не число, которое ему пришлось вспоминать
MYOB — ветви AR и AP для тех, кто работает в MYOB. Только чтение, и в нём вообще нет банковских и кассовых остатков — никогда не бери начальный остаток оттуда

Логика прогноза не меняется. Это дополнительные ветви в ту же модель.

Запуск по расписанию

Этот скилл можно ставить на расписание. Ежемесячный пресет — это предупреждение о деньгах до смены месяца.

Предложи его один раз, после прогноза, который владельцу показался полезным:

Хотите получать это ежемесячно, за несколько дней до конца месяца? Тогда
это полезнее всего, и это тот же прогноз, который вы только что получили.

Расписание — свойство этого скилла. Отдельной команды для него нет.

Сводные поля QuickBooks врут. Прочитай ../../shared/quickbooks-report-traps.md, прежде чем цитировать любой итог из сводного объекта QuickBooks: сводка возрастного анализа AP включает кредиты поставщиков в корзины нетто и может показать отрицательную просроченную сумму, а сводка P&L может показать нулевые расходы при наличии реальных строк. Складывай строки или используй вызов детализации.

Справочные файлы

Файл	Когда загружать
`reference/gotchas.md`	Когда коннектор вернул неожиданные данные или разброс экстремальный
`reference/examples/worked-example.md`	Когда нужно смоделировать формат результата для нового вида данных

Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс работал с инструментом, который не подключён или не указан, предложи build-connector: он сначала проверяет каталог коннекторов, а иначе подключает через Zapier и никогда не собирает вручную обращения к «сырому» API. Когда подключение создано, инструмент входит в этот скилл как любой другой необязательный коннектор, с теми же шлагбаумами согласования.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/cash-flow-snapshot, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: cash-flow-snapshot
description: >
Reads AR/AP, historical cash timing, and known fixed costs from the ledger
(MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) or from PayPal, Square, or Stripe — or
a CSV upload — and produces a 30/60/90-day cash flow forecast with
percentage-variance confidence bands and named risk flags. Delivers a chat
summary and a downloadable XLSX. Use when the user asks "forecast my cash
flow," "will I make payroll," mentions "runway," or says "cash crunch."
Falls back to CSV upload when no connector is live.
compatibility: "Requires one or more of: a ledger MCP (MYOB, NetSuite, QuickBooks, Xero, Zoho Books), PayPal MCP, Shopify MCP, Square MCP, Stripe MCP, file upload (CSV fallback). Output uses xlsx skill."
allowed-tools: Read, WebFetch
---

# Cash Flow Snapshot

Produces a 30/60/90-day cash flow forecast with percentage-variance confidence
bands and named risk flags. Delivers a two-part output: a concise chat summary
and a downloadable XLSX workbook.

**Quick start**

> "Will I make payroll next month?"

Claude pulls the current bank balance, AR/AP, and fixed costs from connected
sources, calculates expected inflows and outflows across 30, 60, and 90-day
windows, applies confidence bands from each customer's payment variance, and
flags specific risks by name.

---

## Workflow

### Step 1 — Identify available data sources

Check which connectors are live. Pull from every one that is, in one batch:

1. The ledger — MYOB, NetSuite, QuickBooks, Xero, or Zoho Books, whichever is connected — for AR aging, AP, fixed costs, and the cash balance. Ledgers are peers (`../../shared/connector-neutrality.md`); if two are connected, ask which is the source of record and take totals from that one only
2. PayPal — transaction history and settlement timing
3. Square — sales and payout history
4. Stripe — charge and payout history
5. Shopify — orders (`list-orders`) as the inflow, plus payout timing. Shopify on its own is enough to run: for a commerce business it is often the largest inflow. The payout read may fail because the connector's scopes exclude Shopify Payments — then ask the owner for their payout schedule and model from that; never infer a lag (`reference/v2_sources.md`)
6. CSV upload — when no connector is connected

If no connector is live and no file is attached, ask the user to either connect
a source or upload a CSV (income/expense tabular data, any reasonable format).
Note which sources were used in the output — this affects confidence band width.

**Always establish the starting cash balance** — "will I make payroll" is a
question about the balance, not the net. Pull it in Step 2, or ask: "What's in
the business account right now, and as of what date?" **Never assume one.** If
nobody knows, head the output "no opening balance — net change only" and drop
cash-on-hand from the risk flags.

### Step 2 — Pull the data

**From the ledger:**
- Balance sheet: bank and cash balances with the as-of date — the opening balance
(MYOB holds none; see `reference/v2_sources.md`)
- AR aging report: customer name, invoice amount, invoice date, due date, days outstanding
- AP: vendor name, amount due, due date
- Recurring fixed costs: rent, payroll, subscriptions (look for recurring transactions)

**From Gusto, when connected:**
- The next payroll run's date and expected amount, and the regular pay-schedule
cadence — the real numbers for the biggest fixed cost, instead of inferring
payroll from recurring transactions. When Gusto and the ledger disagree on
payroll, trust Gusto for timing and amount and say so in the output

**From PayPal / Stripe / Square:**
- Settlement history: transaction date, amount, settlement date
- Use settlement lag (transaction date → payout date) to compute each source's
average and variance payment delay

**From CSV upload:**
- Parse as income/expense tabular data
- Required columns (flexible naming): date, amount, type (income or expense), description
- If columns are ambiguous, show the header row and ask the user to confirm mapping

### Step 3 — Compute historical payment timing

For each AR customer (or income source from CSV), calculate:
- **Mean payment lag** — average days from invoice/transaction date to receipt
- **Payment variance** — standard deviation of payment lag across last 6–12 payments
- Use variance to set confidence band width (see Step 4)

If fewer than 3 payments exist for a customer, use the population mean as the
point estimate and apply a ±30% variance band as the default. When running on
CSV data with sufficient history (≥3 payments per source), compute the band
from the actual payment variance — do not assume ±30%.

### Step 4 — Build the 30/60/90-day forecast

Produce three time windows: 0–30 days, 31–60 days, 61–90 days.

For each window, compute:

| Line | Method |
|---|---|
| Expected inflows | AR due in window, adjusted for mean payment lag |
| Expected outflows | AP due in window + fixed costs falling in window |
| Net cash position | Inflows − Outflows |
| Confidence band | ± weighted average payment variance as a % of expected inflows |

Confidence band formula:
```
band_pct = weighted_avg_stddev_days / avg_payment_lag_days
low = net_cash × (1 − band_pct)
high = net_cash × (1 + band_pct)
```

Round band_pct to one decimal place. Cap at ±50% — higher variance means the
data is too thin to model; flag it instead (see Step 5).

### Step 5 — Flag named risks

Scan for conditions that push the low-band estimate negative or create a
liquidity crunch. For each risk found, produce a one-line flag:

- **Late-payer risk:** "Customer X historically pays 18 days late; that shifts
their USD 8,400 invoice out of the 30-day window into day 48."
- **Payroll crunch:** "Payroll (USD 22,000) hits April 15. Opening balance USD 31,000
on April 1, plus inflows, minus outflows, puts low-band cash on hand April 14
at USD 19,200. Shortfall risk: USD 2,800." Needs a sourced balance.
- **Thin data warning:** "Only 2 payments on record for Customer Y — confidence
band set to default ±30%."
- **No-connector warning:** "Running on CSV data only — no real-time AP or
recurring cost data. Confidence bands are wider than normal."

Limit to the top 5 risks by severity (largest dollar impact first).

### Step 6 — Deliver outputs

**Chat summary** (always). Use a markdown table for the forecast, not a fenced
code block — the chat surface renders markdown tables; a fenced block shows up
as raw monospace text. Shape:

- Title line: Cash Flow Snapshot — <date range>
- Source(s): <connectors used>
- Opening balance: AUD X,XXX as of <date> (or: none on file — net change only)

Then the forecast as a markdown table, amounts carrying the business's currency
code (`../../shared/currency-and-locale.md`), never a bare symbol:

| Window | Expected | Low | High |
|---|---|---|---|
| 30-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |
| 60-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |
| 90-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |

Then risks as a short bulleted list under "⚠ Risks flagged: <count>".

**XLSX workbook** (always): read `xlsx/SKILL.md` first, then produce three sheets:

1. **Summary** — the 30/60/90 forecast table with confidence bands. Beneath
each window row, expand inline sub-rows showing the individual transactions
that make up its inflows (green) and outflows (red). This makes the estimates
auditable without leaving the Summary sheet.

2. **Detail** — all transactions grouped by window, sorted by date within each
group. Include a running net column (cumulative inflows minus outflows within
the window) and a subtotal row at the bottom of each window showing total
inflows, total outflows, and net. Grey out past transactions in a separate
section at the bottom for reference. Ensure all three windows have rows even
if one is empty — show a "No transactions in this window" placeholder row.

3. **Risks** — the flagged risks with dollar impact and affected window.

Save as `cash-flow-snapshot-[YYYY-MM-DD].xlsx`.

**The forecast page** (always, alongside the chat summary — never instead of
it), delivered per the owner's stored output preference — never default to a
markdown file. Check the `## Business context` block's `Output preference`
(shared style guide rule, `../../shared/artifact-style.md`):

- **Visual artifact (the default):** render the full forecast as an HTML page
in the house style. The 30/60/90-day nets are stat tiles with the confidence
range as each tile's context line; the transaction detail is a table with
right-aligned tabular-nums amounts; each risk flag carries a status pill —
critical for a projected shortfall, warn for late-payer and thin-data flags;
sources and opening balance sit in a small header panel.
- **docx / md / notion / canva preference:** deliver the same content in that
form — a DOCX or markdown file, a Notion page created via the connector
(named destination, never overwriting), or a Canva Doc created via the Canva
connector (a new design each run, named with the date; tables become
lists); fall back to the visual artifact if Notion or Canva is not
connected — and say that is why. The XLSX still ships alongside.
- **Best for skill:** use the visual artifact — a forecast is read at a glance
and re-run often.

---

## After the run

One line on what just happened: the forecast is built and the risks are named.
Then offer the single most relevant next step, plus at most two others nearby:

- If a payroll crunch was flagged: "can I make payroll" runs `/plan-payroll`.
- "Who owes me money?" runs `invoice-chase` to pull collections forward.
- "Close the month" runs `/close-month` so next forecast runs on clean books.

Max three offers, and never repeat an offer the owner declined this session.

## Approval gates

This skill is read-only — no approval gate before generating the forecast.

Remind the user after delivery:
> "This forecast is based on [sources listed]. It is not a substitute for
> accounting advice — verify with your bookkeeper before making financing decisions."

---

## More sources, and a schedule

Read `reference/v2_sources.md` for the full mapping:

- **Shopify** — payments inflow timing, which is often the largest single inflow for a commerce business and settles on a delay worth modeling
- **NetSuite** — a ledger of record, common at the larger end of the segment: AR, AP, fixed costs, and the cash balance via reports and SuiteQL
- **Xero** — a ledger of record: aged receivables, bills, bank balances, and the organisation's currency and financial year
- **Ramp** — card spend that hasn't hit the books yet, which is the most common reason a forecast is quietly optimistic
- **Ramp balances** — real business and treasury account balances with history. When the owner banks with Ramp this is a sourced opening balance rather than a number they had to remember
- **MYOB** — AR and AP legs for MYOB shops. Read-only, and it holds **no bank or cash balances at all** — never source an opening balance from it

Nothing about the forecast logic changes. These are additional legs into the same model.

### Running on a schedule

This skill is schedulable. The monthly preset is a cash heads-up before the month turns.

Offer it once, after a forecast the owner found useful:

```
Want this monthly, a few days before month end? That's when it's most useful,
and it's the same forecast you just got.
```

Scheduling is a property of this skill. There is no separate command for it.

**QuickBooks summary fields lie.** Read `../../shared/quickbooks-report-traps.md` before quoting any total from a QuickBooks summary object: the AP aging summary nets vendor credits into its buckets and can show a negative overdue figure, and the P&L summary can report expenses as zero against real rows. Total the rows, or use the detail call.

## Reference files

| File | Load when |
|---|---|
| `reference/gotchas.md` | When a connector returns unexpected data or variance is extreme |
| `reference/examples/worked-example.md` | When modeling the output format for a new data shape |

## Using a tool that isn't listed

The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.

Источник: anthropics/knowledge-work-plugins / small-business / cash-flow-snapshot ↗. Ссылка проверена 2026-10-10.

---
name: cash-flow-snapshot
description: >
  Читает дебиторскую и кредиторскую задолженность (AR/AP), историю сроков
  поступления денег и известные постоянные расходы из учётной системы (MYOB,
  NetSuite, QuickBooks, Xero или Zoho Books) либо из PayPal, Square или Stripe —
  или из загруженного CSV — и строит прогноз денежного потока на 30/60/90
  дней с доверительными коридорами по процентному разбросу и названными
  флагами рисков. Выдаёт сводку в чате и XLSX для скачивания. Используй, когда
  пользователь просит «спрогнозируй мой денежный поток», «хватит ли мне на
  зарплату», упоминает «запас хода (runway)» или говорит «кассовый разрыв».
  Когда живого коннектора нет, переходит на загрузку CSV.
compatibility: "Requires one or more of: a ledger MCP (MYOB, NetSuite, QuickBooks, Xero, Zoho Books), PayPal MCP, Shopify MCP, Square MCP, Stripe MCP, file upload (CSV fallback). Output uses xlsx skill."
allowed-tools: Read, WebFetch
---

# Срез денежного потока

Строит прогноз денежного потока на 30/60/90 дней с доверительными коридорами по процентному разбросу и названными флагами рисков. Выдаёт результат из двух частей: краткую сводку в чате и рабочую книгу XLSX для скачивания.

**Быстрый старт**

> «Хватит ли мне денег на зарплату в следующем месяце?»

Claude достаёт текущий банковский остаток, AR/AP и постоянные расходы из подключённых источников, рассчитывает ожидаемые поступления и выплаты по окнам в 30, 60 и 90 дней, применяет доверительные коридоры по разбросу сроков оплаты каждого клиента и называет конкретные риски.

---

## Рабочий процесс

### Шаг 1. Определи доступные источники данных

Проверь, какие коннекторы работают. Бери данные из каждого, который работает, одной пачкой:

1. Учётная система — MYOB, NetSuite, QuickBooks, Xero или Zoho Books, какая подключена — для возрастного анализа AR, AP, постоянных расходов и денежного остатка. Учётные системы равноправны (`../../shared/connector-neutrality.md`); если подключены две, спроси, какая из них источник истины, и бери итоги только из неё
2. PayPal — история транзакций и сроки расчётов
3. Square — история продаж и выплат
4. Stripe — история списаний и выплат
5. Shopify — заказы (`list-orders`) как поступления, плюс сроки выплат. Одного Shopify достаточно, чтобы начать: для торгового бизнеса это часто самое крупное поступление. Чтение выплат может не получиться, если права коннектора не включают Shopify Payments — тогда спроси у владельца график выплат и моделируй по нему; никогда не выводи задержку из догадок (`reference/v2_sources.md`)
6. Загрузка CSV — когда ни один коннектор не подключён

Если нет ни живого коннектора, ни приложенного файла, попроси пользователя подключить источник или загрузить CSV (табличные данные о доходах и расходах в любом разумном формате). Отметь в результате, какие источники использованы: это влияет на ширину доверительного коридора.

**Всегда определяй начальный остаток денег** — «хватит ли на зарплату» это вопрос про остаток, а не про чистое изменение. Достань его на шаге 2 или спроси: «Сколько сейчас на счёте компании и на какую дату?» **Никогда не предполагай остаток.** Если никто не знает, озаглавь результат «нет начального остатка — только чистое изменение» и убери деньги на руках из флагов рисков.

### Шаг 2. Достань данные

**Из учётной системы:**
- Баланс: банковские и кассовые остатки с датой, на которую они посчитаны, — начальный остаток (в MYOB их нет; см. `reference/v2_sources.md`)
- Отчёт возрастного анализа AR: имя клиента, сумма инвойса, дата инвойса, срок оплаты, дни просрочки
- AP: имя поставщика, сумма к оплате, срок оплаты
- Повторяющиеся постоянные расходы: аренда, зарплата, подписки (ищи повторяющиеся транзакции)

**Из Gusto, если подключён:**
- Дата и ожидаемая сумма следующей выплаты зарплаты и обычная периодичность выплат — настоящие цифры для самого крупного постоянного расхода вместо вывода зарплаты из повторяющихся транзакций. Когда Gusto и учётная система расходятся по зарплате, доверяй Gusto в части срока и суммы и скажи об этом в результате

**Из PayPal / Stripe / Square:**
- История расчётов: дата транзакции, сумма, дата расчёта
- Используй задержку расчёта (дата транзакции → дата выплаты), чтобы вычислить среднюю задержку оплаты и её разброс по каждому источнику

**Из загруженного CSV:**
- Разбери как табличные данные о доходах и расходах
- Обязательные столбцы (названия могут быть любыми): дата, сумма, тип (доход или расход), описание
- Если столбцы неоднозначны, покажи строку заголовков и попроси пользователя подтвердить соответствие

### Шаг 3. Посчитай историческую динамику оплат

Для каждого клиента из AR (или источника дохода из CSV) вычисли:
- **Среднюю задержку оплаты** — среднее число дней от даты инвойса/транзакции до поступления
- **Разброс оплаты** — стандартное отклонение задержки оплаты за последние 6–12 платежей
- Разброс задаёт ширину доверительного коридора (см. шаг 4)

Если по клиенту меньше 3 платежей, возьми среднее по всей выборке как точечную оценку и примени по умолчанию коридор ±30%. Когда работаешь по CSV с достаточной историей (≥3 платежей на источник), считай коридор по фактическому разбросу оплаты — не принимай ±30%.

### Шаг 4. Построй прогноз на 30/60/90 дней

Построй три временных окна: 0–30 дней, 31–60 дней, 61–90 дней.

Для каждого окна вычисли:

| Строка | Метод |
|---|---|
| Ожидаемые поступления | AR к оплате в окне с поправкой на среднюю задержку оплаты |
| Ожидаемые выплаты | AP к оплате в окне + постоянные расходы, попадающие в окно |
| Чистая денежная позиция | Поступления − Выплаты |
| Доверительный коридор | ± средневзвешенный разброс оплаты в % от ожидаемых поступлений |

Формула доверительного коридора:
```
band_pct = weighted_avg_stddev_days / avg_payment_lag_days
low  = net_cash × (1 − band_pct)
high = net_cash × (1 + band_pct)
```

Округляй band_pct до одного знака после запятой. Ограничь ±50% — более высокий разброс означает, что данных слишком мало для моделирования; отметь это флагом (см. шаг 5).

### Шаг 5. Назови риски флагами

Просмотри условия, которые уводят нижнюю оценку в минус или создают нехватку ликвидности. По каждому найденному риску составь однострочный флаг:

- **Риск позднего плательщика:** «Клиент X обычно платит с опозданием на 18 дней; из-за этого его инвойс на 8 400 USD выпадает из 30-дневного окна и приходит на 48-й день».
- **Нехватка на зарплату:** «Зарплата (22 000 USD) уходит 15 апреля. Начальный остаток 31 000 USD на 1 апреля плюс поступления минус выплаты дают нижнюю оценку денег на руках 14 апреля в 19 200 USD. Риск нехватки: 2 800 USD». Нужен остаток с указанным источником.
- **Предупреждение о нехватке данных:** «По клиенту Y в истории только 2 платежа — доверительный коридор принят по умолчанию ±30%».
- **Предупреждение об отсутствии коннектора:** «Расчёт идёт только по данным CSV — нет данных о кредиторской задолженности и повторяющихся расходах в реальном времени. Доверительные коридоры шире обычного».

Ограничься пятью главными рисками по тяжести (сначала с наибольшей суммой в долларах).

### Шаг 6. Выдай результаты

**Сводка в чате** (всегда). Для прогноза используй markdown-таблицу, а не блок кода: интерфейс чата отрисовывает markdown-таблицы, а блок кода выглядит как сырой моноширинный текст. Форма:

- Строка заголовка: Срез денежного потока — <диапазон дат>
- Источники: <использованные коннекторы>
- Начальный остаток: AUD X,XXX на <дата> (или: нет данных — только чистое изменение)

Затем прогноз markdown-таблицей, суммы с кодом валюты бизнеса (`../../shared/currency-and-locale.md`), а не с голым символом:

| Окно | Ожидаемо | Низкая оценка | Высокая оценка |
|---|---|---|---|
| Чистый итог за 30 дней | AUD X,XXX | AUD X,XXX | AUD X,XXX |
| Чистый итог за 60 дней | AUD X,XXX | AUD X,XXX | AUD X,XXX |
| Чистый итог за 90 дней | AUD X,XXX | AUD X,XXX | AUD X,XXX |

Затем риски коротким списком под строкой «⚠ Отмечено рисков: <число>».

**Рабочая книга XLSX** (всегда): сначала прочитай `xlsx/SKILL.md`, затем создай три листа:

1. **Сводка** — таблица прогноза на 30/60/90 дней с доверительными коридорами. Под строкой каждого окна разверни вложенные строки с отдельными транзакциями, из которых складываются его поступления (зелёным) и выплаты (красным). Так оценки можно проверить, не покидая листа «Сводка».

2. **Детали** — все транзакции, сгруппированные по окнам и отсортированные по дате внутри группы. Добавь столбец нарастающего чистого итога (накопленные поступления минус выплаты внутри окна) и итоговую строку внизу каждого окна: всего поступлений, всего выплат и чистый итог. Прошедшие транзакции приглуши серым в отдельном разделе внизу для справки. Следи, чтобы у всех трёх окон были строки, даже если одно пустое, — покажи строку-заглушку «Нет транзакций в этом окне».

3. **Риски** — отмеченные риски с суммой в долларах и затронутым окном.

Сохрани как `cash-flow-snapshot-[YYYY-MM-DD].xlsx`.

**Страница прогноза** (всегда, рядом со сводкой в чате — а не вместо неё), в формате, который владелец сохранил как предпочтительный; никогда не делай по умолчанию markdown-файл. Проверь `Output preference` в блоке `## Business context` (правило общего руководства по стилю, `../../shared/artifact-style.md`):

- **Визуальный артефакт (по умолчанию):** оформи полный прогноз как HTML-страницу в фирменном стиле. Чистые итоги на 30/60/90 дней — плитки показателей, в поясняющей строке каждой плитки — доверительный диапазон; детали транзакций — таблица с суммами, выровненными по правому краю цифрами одинаковой ширины (tabular-nums); каждый флаг риска несёт плашку статуса — критично для прогнозируемой нехватки, внимание для флагов позднего плательщика и нехватки данных; источники и начальный остаток лежат в небольшой панели в шапке.
- **Предпочтение docx / md / notion / canva:** выдай то же содержимое в этой форме — файл DOCX или markdown, страницу Notion, созданную через коннектор (с названным местом назначения, ничего не перезаписывая), или документ Canva Doc, созданный через коннектор Canva (новый дизайн при каждом прогоне, с датой в названии; таблицы превращаются в списки); если Notion или Canva не подключены, вернись к визуальному артефакту и скажи, что причина в этом. XLSX всё равно идёт в комплекте.
- **Лучше всего для скилла:** визуальный артефакт — прогноз читают с одного взгляда и часто пересчитывают.

---

## После прогона

Одна строка о том, что произошло: прогноз построен, риски названы. Затем предложи единственный самый уместный следующий шаг и не больше двух других рядом:

- Если отмечена нехватка на зарплату: «хватит ли мне на зарплату» запускает `/plan-payroll`.
- «Кто мне должен деньги?» запускает `invoice-chase`, чтобы приблизить поступления.
- «Закрой месяц» запускает `/close-month`, чтобы следующий прогноз шёл по чистому учёту.

Не больше трёх предложений, и никогда не повторяй предложение, от которого владелец отказался в этой сессии.

## Шлагбаумы согласования

Этот скилл только читает — шлагбаума согласования перед созданием прогноза нет.

После выдачи напомни пользователю:
> «Этот прогноз основан на [перечисленные источники]. Он не заменяет бухгалтерскую консультацию — проверьте с вашим бухгалтером, прежде чем принимать финансовые решения».

---

## Другие источники и расписание

Полное соответствие смотри в `reference/v2_sources.md`:

- **Shopify** — сроки поступлений платежей, что для торгового бизнеса часто самое крупное единичное поступление, и расчёт идёт с задержкой, которую стоит моделировать
- **NetSuite** — учётная система-источник истины, распространённая на крупном краю сегмента: AR, AP, постоянные расходы и денежный остаток через отчёты и SuiteQL
- **Xero** — учётная система-источник истины: возрастной анализ дебиторской задолженности, счета к оплате, банковские остатки, а также валюта организации и финансовый год
- **Ramp** — расходы по картам, ещё не попавшие в учёт, что чаще всего и делает прогноз тихо оптимистичным
- **Остатки Ramp** — реальные остатки на бизнес- и казначейских счетах с историей. Когда владелец обслуживается в Ramp, это начальный остаток с указанным источником, а не число, которое ему пришлось вспоминать
- **MYOB** — ветви AR и AP для тех, кто работает в MYOB. Только чтение, и в нём **вообще нет банковских и кассовых остатков** — никогда не бери начальный остаток оттуда

Логика прогноза не меняется. Это дополнительные ветви в ту же модель.

### Запуск по расписанию

Этот скилл можно ставить на расписание. Ежемесячный пресет — это предупреждение о деньгах до смены месяца.

Предложи его один раз, после прогноза, который владельцу показался полезным:

```
Хотите получать это ежемесячно, за несколько дней до конца месяца? Тогда
это полезнее всего, и это тот же прогноз, который вы только что получили.
```

Расписание — свойство этого скилла. Отдельной команды для него нет.

**Сводные поля QuickBooks врут.** Прочитай `../../shared/quickbooks-report-traps.md`, прежде чем цитировать любой итог из сводного объекта QuickBooks: сводка возрастного анализа AP включает кредиты поставщиков в корзины нетто и может показать отрицательную просроченную сумму, а сводка P&L может показать нулевые расходы при наличии реальных строк. Складывай строки или используй вызов детализации.

## Справочные файлы

| Файл | Когда загружать |
|---|---|
| `reference/gotchas.md` | Когда коннектор вернул неожиданные данные или разброс экстремальный |
| `reference/examples/worked-example.md` | Когда нужно смоделировать формат результата для нового вида данных |

## Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс работал с инструментом, который не подключён или не указан, предложи `build-connector`: он сначала проверяет каталог коннекторов, а иначе подключает через Zapier и никогда не собирает вручную обращения к «сырому» API. Когда подключение создано, инструмент входит в этот скилл как любой другой необязательный коннектор, с теми же шлагбаумами согласования.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/cash-flow-snapshot, лицензия Apache-2.0. Изменения: перевод на русский язык.