israeli-e-invoice
Israeli E-Invoice
Instructions
Step 1: Determine Invoice Type
Ask the user what type of document they need:
| Code | Hebrew | English | When to Use |
|---|---|---|---|
| 300 | hashbonit mas | Tax Invoice | B2B sales, services over threshold |
| 305 | hashbonit mas / kabala | Tax Invoice / Receipt | B2C with immediate payment |
| 310 | hashbonit zikui | Credit Invoice | Refunds, corrections, returns |
| 320 | kabala | Receipt | Payment confirmation only |
| 330 | hashbonit proforma | Proforma Invoice | Quotes, pre-billing (no allocation needed) |
Step 2: Collect Required Fields
For all invoice types, gather:
- Seller details: Business name, TIN (mispar osek), address, phone
- Buyer details: Business name (or individual), TIN (if B2B), address
- Transaction: Date, item descriptions, quantities, unit prices
- Payment: Method (cash, transfer, check, credit card), terms
Step 3: Calculate VAT
- Standard Israeli VAT rate: Always verify current rate with the Tax Authority (standard rate is 17% as of 2024-2026, but rates may change)
- VAT calculation:
vat_amount = net_amount * vat_rate - Total:
gross_amount = net_amount + vat_amount - For VAT-exempt transactions (osek patur), no VAT line -- use receipt (320) instead
Step 4: Check Allocation Number Requirement
Determine if an allocation number is needed:
- Required if: Invoice amount >= current threshold AND invoice type is 300, 305, or 310
- Current thresholds: Always verify current thresholds with the Tax Authority, as requirements change over time
- Not required for: Receipts (320), proforma (330), invoices below threshold
If allocation number IS required:
- Inform user they must request from SHAAM before issuing
- Provide the API call structure (see references/shaam-api-reference.md)
- The allocation number must appear on the printed/sent invoice
Step 5: Generate Invoice Document
Create the invoice with all fields formatted per Israeli standards:
- Date in both Gregorian (DD/MM/YYYY) and Hebrew calendar
- Amounts in NIS (New Israeli Shekel)
- VAT breakdown as separate line
- Sequential invoice number from seller's series
- Allocation number (if applicable)
Step 6: Validate
Run validation checks:
- All required fields present
- TIN format valid (9 digits with check digit)
- VAT calculation correct
- Invoice number sequential
- Date not in the future
- Allocation number present if above threshold
If validation fails, report specific errors and how to fix them.
Examples
Example 1: Simple B2B Tax Invoice
User says: "Create a tax invoice for a web development project, 15,000 NIS to ABC Ltd" Actions:
- Identify: Tax Invoice (type 300), above threshold -- allocation needed
- Collect: Seller and buyer details
- Calculate: Net 15,000 + VAT (at current rate) = Total amount
- Guide: Request allocation number from SHAAM
- Generate: Formatted invoice document Result: Complete tax invoice with all required fields and allocation number guidance
Example 2: Small B2C Receipt
User says: "I need a receipt for a 500 NIS cash payment" Actions:
- Identify: Receipt (type 320), below threshold -- no allocation needed
- Collect: Seller and buyer details
- Generate: Receipt document Result: Simple receipt, no allocation number required
Example 3: Credit Invoice for Refund
User says: "I need to issue a credit note for invoice #1234, partial refund of 3,000 NIS" Actions:
- Identify: Credit Invoice (type 310)
- Reference: Original invoice #1234
- Calculate: Credit amount with VAT reversal
- Check: Allocation requirement based on amount Result: Credit invoice referencing original, with correct VAT reversal
Bundled Resources
Scripts
scripts/validate_invoice.py— Validates Israeli e-invoice JSON against SHAAM requirements: checks required fields, TIN (mispar osek) format and check digit, invoice type codes, VAT calculation accuracy, and allocation number thresholds. Also referenced in Troubleshooting below. Run:python scripts/validate_invoice.py --help
References
references/shaam-api-reference.md— SHAAM (Tax Authority) API endpoints for requesting allocation numbers, OAuth2 authentication setup, and request/response formats. Consult when integrating with the SHAAM e-invoice API. Also referenced in Step 4 above.references/invoice-types.md— Complete listing of Israeli invoice type codes (300, 305, 310, 320, 330, 400) with required fields per type, VAT applicability, and allocation number requirements. Consult when determining which invoice type to use.references/compliance-timeline.md— Progressive e-invoice mandate timeline per Amendment 157 to the VAT Law, showing threshold reductions from 25,000 NIS down to all invoices. Consult when checking current allocation number thresholds.
Gotchas
- Israeli e-invoices require a SHAAM allocation number (mispar hiktza'a) from the Tax Authority. Agents may generate invoices without this number, making them non-compliant.
- The e-invoice XML schema follows the Israeli Tax Authority specification, not the European Peppol or UBL standard. Agents may generate UBL-formatted XML that Israeli systems cannot process.
- Starting from 2024, Israeli businesses above the turnover threshold must issue e-invoices. Agents may not check whether the business meets this threshold before skipping e-invoice requirements.
- The SHAAM system validates the buyer's tax ID (mispar osek) in real-time. Agents may use placeholder or invalid tax IDs that will be rejected by the validation service.
Troubleshooting
Error: "Invalid TIN format"
Cause: Israeli TIN (mispar osek) must be exactly 9 digits with valid check digit Solution: Verify the number with the check digit algorithm. Run scripts/validate_invoice.py for validation.
Error: "Allocation number required"
Cause: Invoice amount exceeds current threshold for mandatory allocation Solution: Request allocation number from SHAAM API before issuing invoice. See Step 4.
Error: "VAT rate mismatch"
Cause: Using incorrect VAT rate (rate changes periodically) Solution: Always verify current rate with the Tax Authority. Check their website or contact them directly for the most up-to-date VAT rate.
Error: "Invoice type not suitable"
Cause: Wrong invoice type selected for the transaction Solution: Review the invoice type table in Step 1. Common mistake: using type 300 when 305 (with receipt) is needed for immediate payment.
More from skills-il/tax-and-finance
shekel-currency-converter
Convert currencies to/from Israeli New Shekel (NIS/ILS) using Bank of Israel official exchange rates. Use when user asks to convert shekels, NIS, ILS, asks about exchange rates, "shaar yatzig" (representative rate), or needs currency conversion for Israeli tax or business purposes. Supports 30+ currencies with current and historical rates. Do NOT use for cryptocurrency or unofficial money exchange rates.
17israeli-arnona-optimizer
Calculate municipal property tax (arnona) for Israeli properties, check discount eligibility, and draft appeal letters to arnona committees. Use when a user needs to estimate arnona payments by municipality, zone, and property usage type, verify eligibility for discounts (olim, soldiers, elderly, disabled, low income, students, single parents), or prepare formal appeals with legal references. Covers all major Israeli municipalities including Tel Aviv, Jerusalem, Haifa, and Beer Sheva. Do NOT use for income tax (mas hachnasa), VAT (maam), or national insurance (bituach leumi) calculations, which fall under separate Israeli tax authorities.
16israeli-crypto-tax-reporter
Calculate cryptocurrency capital gains tax per Israeli Tax Authority (Reshut HaMisim) regulations and generate Form 1322/1325 reporting data and Form 1399י advance-payment data (within 30 days of disposal). Use when a user needs to compute crypto tax obligations using FIFO cost basis, classify DeFi income (staking, liquidity mining, airdrops) for Israeli tax purposes, prepare annual tax filing data, understand reporting thresholds and advance payment (mikdamot) requirements, or evaluate the 2025-2026 Voluntary Disclosure Procedure (open until 31 Aug 2026). Covers Section 88 of the Income Tax Ordinance, Circular 2018/05, the 25% capital gains rate for individuals, and the 5% surtax on capital income above NIS 721,560 (threshold frozen through 2027). Do NOT use for non-Israeli tax jurisdictions, general income tax calculations, or VAT (maam) on crypto business activities, which require separate professional consultation.
16green-invoice
Integrate Green Invoice (Morning) API for Israeli invoicing, receipts, client management, and payment processing. Use when user asks to create invoices via Green Invoice, generate hashbonit mas through Morning API, manage clients in Green Invoice, set up webhook automation for document creation, query documents or expenses, or mentions "Green Invoice", "Morning", "hashbonit yeruka", "greeninvoice API", Israeli cloud invoicing, or needs to create tax invoice-receipt (cheshbonit mas/kabala). Covers all 13 document types, 8 payment types, client CRUD, item catalog, and webhook integration. Do NOT use for SHAAM allocation numbers or Tax Authority e-invoice compliance (use israeli-e-invoice), Cardcom payment processing (use cardcom-payment-gateway), or Tranzila integration (use tranzila-payment-gateway).
15israeli-pension-advisor
Navigate the Israeli pension and savings system including pension funds (keren pensia), manager's insurance (bituach menahalim), training funds (keren hishtalmut), and retirement planning. Use when user asks about Israeli pension, \"pensia\", \"keren hishtalmut\", retirement savings, \"bituach menahalim\", pension contributions, or tax benefits from savings. Uninformed pension decisions cost hundreds of thousands of NIS over a lifetime. Covers mandatory pension, voluntary savings, and withdrawal rules. Do NOT provide specific investment recommendations or fund performance comparisons.
15israeli-payment-orchestrator
Orchestrate Israeli payment gateways (Cardcom, Tranzila, PayMe, Meshulam, iCredit, Pelecard) with unified routing, fallback, and installments (tashlumim). Use when user asks about multi-gateway payment integration, "slikat kartisim", "tashlumim", payment routing, Shva network, BOI payment-services regulation, gateway comparison, or building a payment abstraction layer for Israeli merchants. Provides unified API patterns, installment handling, Shva clearing rules, and regulatory compliance. Do NOT use for single gateway setup (use cardcom-payment-gateway or tranzila-payment-gateway instead).
15