Payment Demand vs Tax Invoice in Israel: What to Send and When

A payment demand asks to be paid; a tax invoice records a transaction. The difference sounds formal and directly affects cash flow and your debtors report: a business sending the wrong document at the wrong stage either asks for money without the customer knowing what for, or records a transaction that is not yet closed.

This is an operational description, not advice. When you are required to issue which document is a question for your accountant and the Tax Authority pages.

The three documents that come before payment

The common confusion is between the first two. A quote sent in order to request payment confuses the customer - they cannot tell whether it is an offer or a bill. A payment demand solves that: it says explicitly "this is the amount, this is what is included, this is how to pay".

When is a payment demand the right tool?

• Payment in advance for a service not yet delivered.
• A deposit on a large engagement, before work begins.
• Collecting from a new customer with no history.
• A staged project, where each stage is requested separately.
• When the customer needs a document for internal approval before they can pay.

The last is common with organisations: a procurement department needs a document with an amount to raise a purchase order, and that is not the moment to send an invoice. A payment demand fills exactly that role.

What a payment demand should contain

• The amount, and a breakdown of what it covers.
• Validity - how long the demand stands.
• Payment methods, ideally with a direct link.
• Full business details.
• A clear note that this is not a tax invoice, and that one will be issued accordingly.

The last item prevents most enquiries: a customer receiving a document with an amount assumes it is an invoice, then asks for it again at month end when they cannot find it in their filing.

How this affects the debtors report

This is the practical point people forget: the system counts as debt whatever you defined as debt. If you work with payment demands and do not close them in the system, the debtors report is wrong in both directions:

• Debt that is not counted - you sent a demand, the customer did not pay, and nobody is tracking it.
• Debt counted twice - a demand and an invoice for the same transaction, both open.

The fix is simple: issue the invoice from within the payment demand, so the system knows it is the same transaction. Most Israeli systems support that conversion, and it is worth testing during a trial - exactly like the other checks in how to choose invoicing software.

What happens when the customer pays

1. The payment is received and matched to the specific demand.
2. The appropriate document is issued - per what you agreed with your accountant.
3. The demand is closed and leaves the debtors report.
4. The customer receives the document, on the same channel.

Step three is the one skipped when working manually, and it is why customers who have paid receive reminders. A simple monthly check - are there open demands that have already been paid - catches it.

Common mistakes

• Sending a quote instead of a payment demand and expecting payment. A quote does not ask for money.
• Sending a tax invoice to speed up payment without checking whether that suits how you work.
• Not stating validity on a demand, leaving it open forever.
• Not linking the demand to the final document, creating two records for one transaction.
• Sending a demand with no payment link, adding a step the customer has to cross.

How this looks in a staged project

In a project-based business this is the most common flow and the easiest one to lose track of. The pattern that works: a payment demand per milestone, describing what that stage covers; issuing the final document per what you agreed with your accountant; and closing each demand separately as it is paid.

What matters is that each demand carries its own number and links to the project, rather than being "the second demand" with no context. Six months later, when somebody asks how much has been paid so far, the answer should be in a report rather than reconstructed from an email thread.

What to do when the customer pays a different amount

This happens more than you would think: the customer rounds, deducts an amount they believe was agreed, or pays two demands in one transfer. All three need the same handling - record what was actually received rather than what you asked for, and either leave the balance open or close both demands accordingly. What you should not do is mark a demand fully paid when part arrived, because then the balance disappears from tracking and nobody returns to it.

Why validity on a demand matters

A payment demand with no expiry stays open forever, and then two things happen: the debtors report fills with lines nobody intends to collect, and a customer can pay an old price months after it changed. A validity of two weeks or a month solves both, and it also creates useful urgency - the same urgency a quote has and a dateless demand loses.

What to measure

Two numbers are enough to know whether the process works: how many payment demands were sent against how many were paid, and the average time from sending to payment. If the rate is low, the problem is almost always one of three - there is no payment link on the demand, there is no validity date, or the description is not clear enough for whoever approves payments on the other side to approve without asking. The check takes a minute a month and it is what reveals that demands sent on one channel get paid far more than another.

Sources

• Israel Tax Authority - Israeli invoices
• Morning - payment demands and quotes
• iCount - document issuing