VAT and Advance Tax Filing: Building a Deadline Calendar That Stays Current

A deadline calendar that survives is not a table of dates but a generator: one official source, a set of rules, and dates derived fresh each year. The Israel Tax Authority publishes an annual notice setting the reporting and payment dates, and every date in your system should point back to it.

This is a technical description of how to build an operational calendar, not tax, legal or accounting advice. The binding dates are the ones in the official publication, and they should be confirmed against it and with your accountant.

Why a hard-coded date table always breaks

A fixed table fails for three separate reasons, and each is sufficient on its own. First, the publication refreshes: the dates are set in a Tax Authority notice per tax year, so the content changes even when the rules do not. Second, the date depends on the actual calendar, because a date landing on a rest day is postponed. Third, the business itself changes: filing frequency, whether there are employees, or opening a withholding file all change which rows are relevant at all.

The familiar outcome is a shared calendar somebody built one January, still on screen two years later, with nobody remembering who last updated it. That is the same failure described in controlling concurrent spreadsheet edits: no source of truth, only copies.

What a rule looks like when the calendar is derived

The idea is to separate the rule from the date. The rule describes a report type, a channel, and what happens when the date lands on a rest day. The date is derived from it each year, after somebody reads the current notice.

source_url and verified_on are the only difference between a calendar you can trust and a list. They do not improve accuracy; they make inaccuracy visible.

What do you do when a date lands on a rest day?

You handle it in the calculation layer, not in the memory of whoever types the dates in. The Tax Authority's annual notice addresses the case where a reporting date falls on the weekly rest day and sets a rule for postponing it. For anyone building a system, that means a real business calendar is required, one that knows rest days and holidays, rather than arithmetic on a day number.

• The business calendar is a separate service, not a condition inside the date-calculating code.
• The same calendar serves both customer reminders and internal deadlines.
• Israeli holidays are not derivable from a Gregorian calendar, so a dedicated data source is needed. That is covered in using an Israeli holidays API for scheduling.
• Every postponement the system computes should be flagged as computed, so somebody can check it against the publication.

What the right output looks like

A screen somebody has to open is not an output. A deadline fails when the person doing the work did not know in time, not when the information was absent from a system. So the output is events and reminders in the channel that person is already in.

• A calendar event per date, linked back to the rule row that produced it.
• At least one advance reminder, spaced by how long preparation actually takes.
• A separate reminder to prepare the data, which is not the same event as the reminder to file.
• A notification when somebody marks a date as done, so redundant reminders stop.
• A short monthly report of what was done and what slipped, sent to the owner.

Separating "prepare" from "file" is what prevents the classic case where the reminder arrives on the day itself, while the data is still open. In a business that produces those figures through a monthly cycle, connect the calendar to the cycle itself, as described in a two-day monthly close process.

How do you test a calendar that derives itself?

A wrong calendar does not shout. It simply fails to send a reminder, and nobody notices until it is late. So testing has to be active rather than relying on somebody spotting a missing message.

• Run the derivation for a full year ahead and compare the result to the official publication, row against row.
• Pay particular attention to months where the date lands on a weekend or near a holiday.
• Confirm every calendar event carries a reference back to the rule row and the source it derived from.
• Simulate a mid-year frequency change and check the old events were cancelled.
• Send a test reminder to a real address, to prove the channel itself works.

That last check sounds redundant and it is the one that fails most often. A system can compute correctly, store correctly, and send nothing because a setting changed in the mail service. A reminder that did not reach a person is indistinguishable from a reminder that was never created.

Who owns the source, and what to check each January

The annual notice is the input. Somebody has to read it when it is published and enter the new values, and that person is almost always the accountant or the bookkeeper rather than whoever wrote the code.

• Who reads the new publication, and when it was checked.
• Which rows changed relative to last year, and which did not.
• Which rows are no longer relevant to the business, for example after a change in filing frequency.
• Whether the filing channel in practice matches what the channel field says.
• Who receives the reminders, and whether that person still holds the role.

Sources

• Setting reporting and payment dates - periodic VAT reports, income tax advances and withholding, Israel Tax Authority
• Israel Tax Authority - official site