Salesforce and Israeli Invoicing: Issuing a Tax Invoice When an Opportunity Closes

To issue an Israeli tax invoice when a Salesforce Opportunity closes, you trigger on the Opportunity becoming won, call the invoicing system's API (Morning, iCount, Invoice4U or Priority) outside the save transaction, and write the document number, document id and allocation number back to the Opportunity. Salesforce never obtains the allocation number itself - the invoicing system does.

Salesforce is a common CRM in Israeli B2B companies, and it has no native connection to Israeli invoicing systems. So the sales team closes a deal in Salesforce and someone retypes it into the invoicing system. This guide covers the integration options Salesforce actually offers, the order of operations that avoids duplicate tax documents, and what changes per invoicing system. If you are still choosing a CRM, the comparison is in HubSpot vs Salesforce.

What should trigger the invoice in Salesforce?

The trigger should be the Opportunity's IsWon field turning true, not a specific stage label. According to Salesforce's object reference, IsWon and IsClosed are booleans controlled by StageName: you can filter on them, but you cannot set them directly. A condition on IsWon keeps working when an admin renames the "Closed Won" stage or adds a second won stage.

Two more fields matter before any amount leaves Salesforce. AccountId points to the customer, where the ח"פ or ת"ז usually lives in a custom field. And Amount, on an Opportunity with products, is the sum of its line items - an update that tries to change it is ignored, not rejected. The invoice lines should therefore come from the Opportunity's products, not from a single total.

Which Salesforce integration option should you use?

The right Salesforce option depends on where the retry logic and the credentials should live. Salesforce offers four realistic routes to call an Israeli invoicing API:

The Flow route is the lightest. Salesforce's release note for the asynchronous path describes it as the way to call an external service after the triggering record is committed, and notes that the path can be delayed when system resources are unavailable - acceptable for an invoice, which should not sit in the user's save anyway. Apex gives full control, with the limits in the table taken from Salesforce's callout documentation: a default timeout of 10 seconds per callout, configurable up to 120,000 milliseconds.

The order of operations, step by step

1. Detect the win. A record-triggered Flow (after save, "Is Changed" on IsWon) or a Change Data Capture subscriber notices the Opportunity closing as won.
2. Mark it pending. Set a custom status field, for example Invoice_Status__c = Pending, so a second trigger does not start a second document.
3. Build the document from the Account (name, ח"פ, email) and the Opportunity products (name, quantity, price), with VAT handling decided per product.
4. Call the invoicing API outside the save transaction, sending the Opportunity id as your own unique reference.
5. Read the result, not only the status code. Parse the response body for errors before treating the call as a success.
6. Write back the document number, the document id and the allocation number to fields on the Opportunity, and set the status to Issued or Failed with the error text.

If the write-back comes from middleware, it is a PATCH to the REST API's sObject Rows resource for that Opportunity (/sobjects/Opportunity/{id}), and it counts toward the org's inbound API allocation.

Where does the allocation number fit?

This section is a technical description, not tax advice. Under the Israel Invoices model, a tax invoice that meets the statutory conditions carries an allocation number (מספר הקצאה) issued by the Tax Authority. In a Salesforce integration the invoicing system requests that number as part of issuing the document; Salesforce's job is to store what comes back and to notice when it did not come back.

Invoice4U, for example, returns AllocationNumber and AllocationMessage on the document, and FetchAllocationNumber requests one for an existing document. Which invoices need a number is set by the Tax Authority and has changed during 2026, so the rule belongs in configuration, never in a Flow condition or an Apex constant. The engineering side, including what to do when the Tax Authority service is slow, is covered in the allocation number API guide. Which documents your business must issue is a question for your accountant.

What changes with each Israeli invoicing system?

The Salesforce side stays the same; the invoicing side differs in authentication and in how errors come back:

• Invoice4U reports business errors inside a 200 response, in a d.Errors array. A Flow HTTP Callout treats only status 300 and above as an error, so without an explicit decision on Errors a failed call looks successful. CreateDocumentWithIdentifierValidation with ApiIdentifier set to the Opportunity id rejects a retry instead of issuing a second document. Details in the Invoice4U API guide.
• iCount's current v3 API takes a token in the Authorization header. Since the Flow action does not accept request headers, that header has to be defined on the Named Credential.
• Morning (Green Invoice) issues short-lived tokens from long-lived API credentials, which must be cached and refreshed. If that exchange does not fit a Named Credential's authentication options, the refresh moves into Apex or middleware. See automating Morning through its API.
• Priority is usually the ERP rather than a standalone invoicing tool, reached over its REST/OData interface, and every installation is customised. A won Opportunity typically becomes an order or invoice in Priority, and the field list comes from the client's own sandbox.

What goes wrong in a Salesforce to invoicing integration

• Duplicate invoices from retries. A timeout does not mean nothing was issued. Always send the Opportunity id as the external reference and check for an existing document before retrying.
• A reopened Opportunity. If a won deal is moved back and won again, the trigger fires twice. The pending or issued status field is what stops the second document.
• Callout after DML. Apex cannot make a callout while DML is pending in the same transaction, which is why the call belongs in a Queueable job or an asynchronous Flow path.
• Hitting the API allocation. Salesforce's allocations are counted for the whole org over 24 hours, not per user: 15,000 calls in Developer Edition, and 100,000 plus per-license calls in Enterprise Edition. Monitor them with the /limits resource or the Sforce-Limit-Info response header.

Professional Edition appears in Salesforce's allocation table only "with API access enabled", so confirm API access on the client's edition before planning any middleware route.

Sources

• Salesforce - API Request Limits and Allocations
• Salesforce Apex Developer Guide - Callout Limits and Limitations
• Salesforce Help - HTTP Callout Considerations and Limits