אוטומציית סגירת חודש וסיווג תנועות עם n8n ו-Claude — מדריך שלב אחר שלב

2. ארכיטקטורת המערכת

שבעה רכיבים, כל אחד ניתן להחלפה. שכבת התזמור היא n8n self-hosted כדי שהמבקר יוכל לבדוק כל קריאת API שנוגעת בנתונים פיננסיים. Postgres הוא מערכת התיעוד לתנועות גולמיות, החלטות סיווג, מסלול ביקורת ומצב אישורים — ה-GL עצמו נשאר ב-QuickBooks או ב-Xero.

הסטאק

הערכת עלות (4,200 תנועות בחודש, 3 ישויות)

רואה חשבון בכיר שמחזיר לעצמו 80 שעות בחודש שווה בערך 6,000 דולר עלות עומס מלא. ה-pipeline משלם על עצמו תוך הסגירה הראשונה, וה-ROI המצטבר נקבע ברובו לפי מה שהצוות עושה עם השעות שהחזרנו — בדרך כלל FP&A, דיווח לדירקטוריון ואיסוף ראיות SOC 2. אותה שכבת תזמור משתלבת בתוך שירותי האוטומציה ה-AI הרחבים שלנו.

שלושה מקורות מזינים את ה-pipeline כל לילה: פיד הבנק וכרטיסי האשראי דרך Plaid, רשימת התנועות הלא-מותאמות מ-QuickBooks או Xero, ומסד הספקים יחד עם מצבת החשבונות (נקראים פעם ביום ונשמרים ב-cache מקומי). Plaid הוא רשת הביטחון — הוא תופס תנועות שנכנסו לבנק אבל מעולם לא הגיעו ל-QBO בגלל תקלת פיד, וזו הסיבה הכי נפוצה לתעלומות "חסר 4,800 דולר" ביום הסגירה.

מקורות webhook ו-poll

• Plaid Transactions: /transactions/sync לילי לכל מוסד. מבוסס cursor, idempotent.
• QuickBooks Online: שאילתה יומית של Purchase, JournalEntry, Bill, CreditCardPayment דרך v3 API.
• Xero: מקבילה דרך BankTransactions ו-ManualJournals עם If-Modified-Since.
• COA + ספקים: נמשכים פעם ביום, מנורמלים לטבלת lookup שטוחה ש-prompt של Claude יכול להפנות אליה בזול.

סכמת תנועה מנורמלת

כל ארבעת המקורות מנורמלים לצורת שורה אחת לפני שהם מגיעים לסיווג. ה-source_hash הוא מפתח ה-dedupe — אותו source ואותו external_id = אותה שורה, גם אם ה-workflow רץ מחדש מאה פעם.

CREATE TABLE staged_transactions (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_id       text NOT NULL,
  source          text NOT NULL,    -- 'plaid' | 'qbo' | 'xero'
  source_hash     text NOT NULL,    -- sha256(source || external_id)
  external_id     text NOT NULL,
  posted_at       date NOT NULL,
  amount_cents    bigint NOT NULL,
  currency        text NOT NULL,
  raw_description text NOT NULL,
  counterparty    text,
  account_ref     text,             -- bank acct or QBO acct id
  payload         jsonb NOT NULL,
  ingested_at     timestamptz DEFAULT now(),
  UNIQUE (source_hash)
) PARTITION BY RANGE (posted_at);

מסווג מבוסס-חוקים נשבר ברגע ששיווק פותח מנוי SaaS חדש או שמשאבי-אנוש מוסיף ספק הטבות. Claude קורא את התנועה יחד עם מצבת החשבונות, היסטוריית הספק וההחלטה של החודש שעבר על אותו counterparty, ומחזיר JSON מובנה עם ביטחון ונימוק. שורות בביטחון גבוה נרשמות אוטומטית; שורות בביטחון נמוך הולכות לתור חריגים.

4 ממדי הסיווג

System prompt לסיווג

ה-COA, רשימת ה-classes ומדיניות ההיוון מוזרקים להקשר ה-prompt בכל ריצה. היסטוריית הספק מסופקת כחמשת הסיווגים האחרונים של אותו counterparty — זה מה שנותן ל-Claude זיכרון, וזה מה שמאפשר לצוות לעקוף החלטות עבר באלגנטיות.

You are a transaction categorizer for a US GAAP SaaS company.

You receive:
- A single bank or ledger transaction
- The full chart of accounts (account number, name, type)
- The class / department list
- The capitalization policy (threshold $2,500, useful life rules)
- The 5 most recent categorizations of the same vendor

Output strict JSON:
{
  "gl_account": "6310",
  "gl_account_name": "Software Subscriptions",
  "class": "Engineering",
  "capex_vs_opex": "opex",
  "accrual_flag": false,
  "confidence": 0.0-1.0,
  "reasoning": "1-2 sentences citing the strongest signals",
  "needs_human_review": true|false
}

Rules:
- If confidence < 0.85, set needs_human_review = true
- If amount > $2,500 AND counterparty looks like equipment/hardware,
  capex_vs_opex = "capex" and needs_human_review = true regardless
- If service period in description spans month-end, accrual_flag = true
- If counterparty doesn't match anything in the vendor master and the
  amount is > $1,000, needs_human_review = true
- NEVER invent a GL account that doesn't exist in the supplied COA

n8n HTTP Request ל-Claude

{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $credentials.anthropic.apiKey }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-sonnet-4-5",
    "max_tokens": 500,
    "system": "{{ $json.categorizerSystemPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": "Transaction:n{{ JSON.stringify($json.txn) }}nnVendor history (last 5):n{{ JSON.stringify($json.vendorHistory) }}nnCOA + classes attached above."
      }
    ]
  }
}

זיכרון ספקים (החלק הזול אבל קריטי)

ספקים חוזרים לא צריכים קריאות Sonnet מלאות. lookup קטן ב-Postgres יחד עם ולידציה של Haiku מטפל ב-85% מהנפח החודשי בעשירית מהעלות.

-- Last 6 months of accepted categorizations per vendor.
-- If 5+ rows agree on the same gl_account, it's a "settled" vendor —
-- route through Haiku for a sanity check, skip the Sonnet call.

WITH stable AS (
  SELECT counterparty,
         gl_account,
         class,
         count(*)                                            AS hits,
         max(approved_at)                                    AS last_seen
  FROM   categorization_decisions
  WHERE  approved_at > now() - interval '6 months'
    AND  reviewer_action IN ('accepted','auto')
  GROUP  BY counterparty, gl_account, class
  HAVING count(*) >= 5
)
SELECT s.*
FROM   stable s
WHERE  s.counterparty = $1
ORDER  BY s.hits DESC, s.last_seen DESC
LIMIT  1;

התאמת יתרות היא מכנית: יתרת בנק מ-Plaid צריכה להיות שווה ליתרת חשבון המזומן ב-GL לפי QBO/Xero, פחות פריטים בתנועה (שיקים שלא נמשכו, הפקדות בדרך). ה-pipeline מחשב את שני הצדדים, מציף כל שבר עם הסיבה הסבירה שלו, ורק מסלים את השברים שלא נסגרים אוטומטית. רוב החודשים, האדם רואה רק שברים ששווה לראות.

חוזה התאמה תלת-כיוונית

• צד הבנק: יתרת Plaid בנקודת חיתוך הסגירה (T+1, 04:00 UTC).
• צד הספרים: יתרת חשבון מזומן ב-QBO/Xero לסוף החודש, עם כל התנועות המאושרות שנרשמו.
• צד ספר עזר: שיקים שלא נמשכו + הפקדות בדרך + העברות ממתינות מטבלת ה-staging של n8n.

אם bank = ledger + subledger, הצב את דגל close-ready על אותו חשבון והמשך הלאה. אחרת, צלול לניתוח שברים.

דפוסי שבר שנפתרים אוטומטית

SQL לאיתור שברים

-- For each bank account, compute the three-way and emit any break.

WITH bank AS (
  SELECT entity_id, account_ref, balance_cents
  FROM   plaid_balances
  WHERE  as_of = $1::date
),
ledger AS (
  SELECT entity_id, account_ref, sum(amount_cents) AS balance_cents
  FROM   ledger_transactions
  WHERE  posted_at <= $1::date
    AND  status = 'posted'
  GROUP  BY entity_id, account_ref
),
subledger AS (
  SELECT entity_id, account_ref, sum(amount_cents) AS in_flight_cents
  FROM   staged_transactions
  WHERE  posted_at <= $1::date
    AND  cleared_at IS NULL
  GROUP  BY entity_id, account_ref
)
SELECT b.entity_id,
       b.account_ref,
       b.balance_cents
         - coalesce(l.balance_cents, 0)
         - coalesce(s.in_flight_cents, 0)        AS break_cents
FROM   bank b
LEFT   JOIN ledger    l USING (entity_id, account_ref)
LEFT   JOIN subledger s USING (entity_id, account_ref)
WHERE  abs(
         b.balance_cents
         - coalesce(l.balance_cents, 0)
         - coalesce(s.in_flight_cents, 0)
       ) > 0;

זיהוי חריגות רץ אחרי הסיווג ולפני הסגירה. שלוש שכבות: שכבה סטטיסטית דטרמיניסטית (זולה, תופסת את רוב הדברים), בדיקת hash לתשלום כפול, ומעבר של Claude על קבוצת החשודים עם הקשר ספקים ועונתיות מלא. המטרה היא לא "למצוא כל תנועה מוזרה" — אלא "להפיק תור קצר ומדורג שהבקר יכול לסגור ב-30 דקות".

השכבה הסטטיסטית

• z-score של סכום ספק: כל תנועה במרחק של יותר מ-3 סטיות תקן מהחציון של 12 החודשים האחרונים לאותו ספק.
• ספק חדש מעל סף: counterparty ראשון בפעם הראשונה עם סכום מעל $5,000.
• קפיצה ב-GL: יתרת חשבון עולה ביותר מ-30% MoM בלי גורם צפוי שמסומן.
• אשכול סכומים עגולים: 3+ תשלומים זהים בסכום עגול באותו שבוע לאותו ספק (סימן קלאסי של kiting).
• סטיית חיתוך תקופה: תאריכי תקופת שירות חוצים את גבול החודש בלי accrual.

Hash לזיהוי תשלום כפול

-- Same vendor, same amount, within 7 days = candidate duplicate.
-- Distinguishes legit recurring (rent) by checking established cadence.

SELECT a.id        AS suspect_id,
       b.id        AS twin_id,
       a.counterparty,
       a.amount_cents,
       a.posted_at AS suspect_posted,
       b.posted_at AS twin_posted
FROM   ledger_transactions a
JOIN   ledger_transactions b
  ON   a.counterparty = b.counterparty
 AND   a.amount_cents = b.amount_cents
 AND   a.entity_id    = b.entity_id
 AND   a.id          <> b.id
 AND   abs(a.posted_at - b.posted_at) BETWEEN 1 AND 7
WHERE  a.posted_at BETWEEN $1 AND $2
  AND  NOT EXISTS (
         SELECT 1 FROM vendor_recurring_cadence r
         WHERE  r.counterparty = a.counterparty
           AND  r.expected_freq_days BETWEEN 1 AND 7
       );

תיעדוף Claude על קבוצת החשודים

השכבה הסטטיסטית מפיקה בדרך כלל 80–150 מועמדים בכל סגירה. Claude קורא כל אחד מהם עם הקשר ספק מלא (12 חודשים אחרונים, קצב ממוצע, תוצאות חריגה קודמות) ומדרג אותם לפי סיכון ביקורת. ה-20 הראשונים נוחתים בתור של הבקר עם תקציר של פסקה אחת על מה שחריג. השאר מקבלים תיוג "סיכון נמוך, מעקב בלבד" ומתגלגלים הלאה.

accruals חוזרים הם החלק עם הכי פחות שיקול דעת והכי הרבה נפח בסגירה — בדיוק המקום שבו Claude מצדיק את העלות החודשית שלו. ה-pipeline קורא את מדיניות ה-accrual, את ספר ה-JE של החודש הקודם ואת הפעילות שנרשמה בחודש הנוכחי, ואז מנסח כל JE שהבקר היה מנסח ידנית. הבקר עדיין צריך לאשר כל אחד מהם; שום דבר לא נרשם ל-GL אוטומטית.

JEs שה-pipeline מנסח

• פריסת prepaid: חוזי SaaS שנתיים, ביטוח, רטיינר ביקורת.
• הוצאות לשלם: שירותים שהתקבלו אך טרם חויבו (משפטי, קבלני משנה, חודש חלקי של AWS).
• שחרור הכנסות נדחות: הכרה בהכנסה לפי לוח ASC 606, לפי חוזה.
• פחת: קו ישר על מרשם הרכוש הקבוע.
• שערוך FX: תרגום לסוף חודש למזומן וחייבים/ספקים במטבע זר.
• accrual לבונוס: לפי השגה רבעונית מול יעד — הבקר חותם על השיעור.

Payload של טיוטת JE (QuickBooks)

{
  "TxnDate": "2026-04-30",
  "DocNumber": "JE-2026-04-018",
  "PrivateNote": "Drafted by Claude. Source: prepaid policy + Datadog annual.",
  "Line": [
    {
      "Amount": 4166.67,
      "DetailType": "JournalEntryLineDetail",
      "Description": "Datadog Pro annual / monthly amortization",
      "JournalEntryLineDetail": {
        "PostingType": "Debit",
        "AccountRef": { "value": "6310", "name": "Software Subscriptions" },
        "ClassRef":   { "value": "ENG",  "name": "Engineering" }
      }
    },
    {
      "Amount": 4166.67,
      "DetailType": "JournalEntryLineDetail",
      "Description": "Release prepaid Datadog month 1 of 12",
      "JournalEntryLineDetail": {
        "PostingType": "Credit",
        "AccountRef": { "value": "1410", "name": "Prepaid Expenses" }
      }
    }
  ],
  "MetaData": {
    "skru_status":      "draft_pending_approval",
    "skru_model":       "claude-sonnet-4-5",
    "skru_workpaper":   "s3://skru-close/2026-04/wp-018.pdf"
  }
}

חבילת הסגירה היא מה שהבקר חותם עליו, מה שוועדת הביקורת קוראת, ומה שמבקר ה-SOC 2 בודק 18 חודשים אחר כך. הפקה שלה מתבנית דטרמיניסטית (במקום Google Doc חצי-מעוצב שמורכב מחדש כל חודש) אומרת שהפורמט עקבי, ה-workpapers מקושרים, ו-hash של התיק מתאים באופן ניתן-לאימות למצב ה-GL בזמן החתימה.

מבנה התיק

1. שער וחתימה — תקופה, ישות, מכין, סוקר, בקר, hash של תצלום ה-GL.
2. דוחות כספיים — רווח והפסד, מאזן, תזרים מזומנים, עם השוואה לתקופה קודמת ולתקציב.
3. התאמות יתרות — כל חשבון מזומן, חייבים, ספקים ושכר, התאמה תלת-כיוונית מצורפת.
4. מרשם פקודות יומן — כל JE של התקופה עם קישור ל-workpaper.
5. פתרון חריגות — מה סומן, מי אישר, מה היה הפתרון.
6. פרשנות סטיות — פרשנות MoM ו-YoY שננסחה על ידי Claude, נערכה על ידי הבקר.
7. מסלול ביקורת — כל קריאת API, גרסת מודל, hash של prompt וחותמת זמן של פעולת אדם.

Prompt לפרשנות סטיות

You are drafting variance commentary for the close binder.

Inputs:
- Current month P&L by GL account
- Prior month and prior-year same-month P&L
- Budget for the current month
- Categorization decisions and notable anomalies for the month
- Major contract starts/ends in the period

For each line where MoM or vs-budget variance is > 10% AND
> $5,000 absolute, write 1-2 plain-English sentences explaining
the most likely driver. Cite specific transactions or contracts.
Never speculate beyond the supplied data. If you don't know, say
"driver not identified — controller review required".

Output format: markdown bullet list, grouped by P&L section
(Revenue, COGS, OpEx, Other), one bullet per material line.

Render PDF + ארכיון בלתי-משתנה

התיק נרנדר עם node של headless Chromium ב-n8n מתבנית HTML עם גרסה. ה-PDF היוצא עובר hash (SHA-256), עולה ל-S3 עם object lock פעיל, וה-hash נכתב לטבלת מסלול הביקורת. הפקה מחדש של התיק לאותה תקופה מייצרת קובץ אחר (חותמות זמן שונות) אבל ה-hash של תצלום ה-GL הבסיסי נשאר זהה — זוהי בדיקת השלמות שאכפת ממנה למבקר.

ברגע שהתיק מופק, ההפצה מכנית ותחומה בזמן. הבקר מקבל DM ב-Slack עם קישור לתיק ועם תור החריגות. ה-CFO מקבל סיכום במייל יחד עם ה-PDF. ועדת הביקורת מקבלת שיתוף read-only ל-S3 עם גישה מבוססת גרסאות. כל שלב נכתב למסלול הביקורת עם חותמת זמן.

מכונת מצבים של אישורים

תיק חתום עובר עוד hash, מאורכב ל-S3 עם object lock, וה-JEs שהיו ב-draft_pending_approval מקובצים לעסקת רישום אחת אל QBO/Xero. הדפוס שומר על GL נקי — שום דבר לא נרשם לפני החתימה, שום דבר לא נרשם אחרי החתימה בלי תיקון מתועד. אותו דפוס handoff מופיע בעבודה שלנו לתעשיית הייעוץ שבה שותפים צריכים חתימה בלתי-הפיכה על תוצרי לקוח.

כשלים נפוצים ותיקונים

שלושה דפוסי כשל מופיעים כמעט בכל deployment של הנה"ח. תכנן מולם מהיום הראשון — זול לעצב סביבם ויקר לתקן בדיעבד.

כשל 1: סיווג בטוח-יתר על ספקי שוליים

סימפטום: ספק SaaS חדש ששמו דומה לקיים (למשל "Notion" מול "Notion AI") מסווג אוטומטית בביטחון 0.93 ונרשם תחת המחלקה הלא נכונה.

תיקון: סף ביטחון לרישום אוטומטי של 0.95, ודרישה ל-שתי החלטות מסכימות קודמות על מחרוזת ספק מנורמלת זהה לפני כל רישום אוטומטי. ספקים חדשים תמיד נדרשים לסקירה אנושית בהופעה הראשונה, לא משנה כמה המודל בטוח.

כשל 2: חיבור מחדש של Plaid מוחק את ה-cursor הקודם

סימפטום: ישות מבצעת אימות מחדש מול Plaid (החלפת MFA), ה-cursor מאופס, וה-sync הבא מכניס מחדש שלושה חודשים של תנועות כחדשות — Claude מסווג מחדש הכל, ומסלול הביקורת נראה כאילו הצוות רשם את התקופה פעמיים.

תיקון: תמיד עשה dedupe ראשון בטבלת ה-staging לפי source_hash. דלג על Claude לחלוטין לכל תנועה שה-source_hash שלה כבר יש לה החלטת סיווג מאושרת ב-18 החודשים האחרונים — קצר את הדרך להחלטה הקודמת ותעד את העובדה.

כשל 3: טיוטת JE נרשמת לפני אישור (תקלת dev-mode)

סימפטום: שינוי workflow מופץ בלי דגל הסביבה הנכון, וטיוטות JE של Claude נרשמות ישירות ל-QBO ה-live במקום להישאר ב-draft_pending_approval.

תיקון: ה-credential של QBO/Xero שה-pipeline משתמש בו חייב להיות חשבון שירות שתפקידו אוסר במפורש לרשום JEs בלי שדה approved_by מאוכלס. הגדר הרשאות ברמת האינטגרציה, לא רק בקוד ה-workflow — קוד יכול לצאת שבור; הרשאות לא יכולות.

ציות: SOC 2, מסלול ביקורת והפרדת תפקידים

pipeline בהנה"ח שכותב ל-GL או אפילו מנסח JEs נמצא בתחולת SOC 2 Type 2 מהיום הראשון אם אתה ספק SaaS, ובתחולת ביקורת הדוחות הכספיים אם אתה חברת פורטפוליו מעל סף המהותיות. תתייחס לציות כאילוץ עיצוב, לא כצ'קליסט בסוף.

מה Claude רואה (ומה לא)

• רואה: תיאורי תנועה, סכומים, שמות ספקים, רשימת חשבונות GL, רשימת classes, היסטוריית ספק (5 החלטות אחרונות), מדיניות היוון, לוחות ASC 606.
• לא רואה: מספרי חשבון בנק, נתוני כרטיסי תשלום, מספרי SSN של עובדים, PII של לקוחות מעבר לשם החברה, אישורי כניסה גולמיים לבנק, קבצים מצורפים מחוץ לסוגי PDF/CSV ב-whitelist.

בקרות SOC 2 Type 2 שזה מספק

• CC7.2 / CC8.1 מסלול ביקורת: כל סיווג, טיוטת JE, פתרון חריגה ואישור נרשמים עם הסוקר, חותמת זמן, גרסת מודל ו-hash של prompt.
• CC6.1 בקרות גישה: כתיבה ל-QBO/Xero דרך חשבון שירות בלבד, credentials של n8n מבוססי-תפקיד, אין מפתחות API משותפים לאדם, סודות ב-vault.
• CC8.1 ניהול שינויים: n8n workflows ב-git, פריסות CI עם אישור, אין עריכות point-and-click ב-prod, גרסאות prompt מתויגות.
• A1.2 / PI1.4 שלמות נתונים: hash chain של חבילת הסגירה, S3 object lock, שמירת partition 7 שנים, workpapers בלתי-משתנים.

הפרדת תפקידים

ה-pipeline לעולם לא סוגר את הלולאה על העבודה של עצמו. אותה זהות שניסחה JE לא יכולה לאשר אותו; אותה זהות שאישרה JE לא יכולה לחתום על התיק. רואה חשבון בכיר מאשר סיווגים וטיוטות JE; הבקר מאשר פתרון חריגות וחותם על התיק; ה-CFO חותם סופית. שלוש זהויות, שלוש פעולות — מקודדות כאילוץ קשיח במכונת המצבים של האישורים, לא כמדיניות שאתה זוכר ליישם.

תוצאות נמדדות — אחרי 6 סגירות

מספרים מ-deployment אמיתי בצוות הנה"ח של חברת SaaS עם 200 עובדים (3 ישויות, 2 מטבעות, ~4,200 תנועות בחודש) אחרי שישה מחזורי סגירה מלאים על ה-pipeline החדש. בלי שינוי במצבת החשבונות או בלוח הסגירה — הניצחון מגיע לחלוטין מעומק האוטומציה ומסקירה לפי חריגים.

המטריקה הראשית במשרד של הבקר היא שיעור הקבלה האוטומטית של סיווגים: 93% מהשורות בביטחון גבוה נרשמו בלי עריכה, עם שיעור שגיאה נמדד מתחת ל-0.4% בביקורת מדגמית. זה המספר שמאפשר להנהלת הכספים לסמוך על ה-pipeline מספיק כדי באמת לשנות התנהגות — וזה המספר שמבקר ה-SOC 2 ביקש קודם.

לוח זמנים ועלות יישום

שאלות נפוצות