Main menu
🔄 Day-to-Day
💡 Quick import & export: Use the green "📊 Excel" button in the top bar for quick actions.
Your password is encrypted and stored locally in the browser.
Enter your password to continue.
🖥️ You are using the browser version. A desktop-software version is available via the email at the bottom of the guide.
What do your data actually "sit" on? In the browser version the data is stored inside the browser itself, tied to the user (profile) you are browsing under — that is the round marker with a letter in the corner of the browser window. As long as you stay on the same computer and the same user, the data is kept and is not erased, even after shutting the computer down and even after months.
By contrast — moving to another computer, switching to a different browser user/profile, or clearing the site's browsing data — will not bring the data with you, because it is stored under that one specific user only. Because of this dependency, the backup is not merely recommended — it is essential, and it is also the only way to carry your data between computers and users.
To make sure the information is never lost, it is recommended to follow these steps:⚠️ Important warning: it is best not to rely on the automatic backup alone; make it a habit to click the manual 🛡️ Backup button before every time you close the app.
The system is designed to compute the set-aside percentage from your net profits, not from all the money that comes in.
Alongside the income column there is a separate expenses column (on a narrow screen you can merge them into one alternating column via the toggle at the top). The expenses recorded there are meant only to offset income for the maaser and chomesh calculation — this is not about all household expenses:
The main screen is built from two tables, each with its own status box in the corner. The difference between the two boxes is the key to understanding the whole system.
Here income is recorded, along with the expenses tied to producing the income. In the corner a balance is shown.
This balance refers only to the month currently shown on screen. Switching to another month in the month selector in the top bar changes it immediately.
This version has two separate set-aside columns: 📊 Maaser management and 📗 Chomesh management. In each you record what was actually set aside for that purpose, and each has its own status box labeled "Calculated from the whole budget" — the most important figure in the system.
Unlike the balance above, this box surveys the entire history from day one: all the profits versus everything set aside, regardless of the month shown.
It shows one of two: Maaser owed on a red background — meaning there is still an amount to set aside, or Maaser surplus on a green background — meaning more was set aside than the obligation.
Why don't the two boxes "agree" with each other? This is the most common point of confusion, and the answer is simple: they measure different time ranges. If you record an action today with an old date — say income from six months ago — the monthly balance for the current month will not change, but the overall obligation box will update, because it counts all dates together.
In this version there is no selector that switches between 10% and 20%. Each column stands on its own with its own calculation, so you can track both set-asides in parallel without one overriding the other. Anyone managing maaser only can simply ignore the chomesh column and leave it empty.
Working with the tables themselves: clicking a column heading (date, description or amount) sorts by it, and clicking again reverses the order. At the bottom of each table there is paging between pages, and in the "Actions" column of each row you can edit or delete it.
Every action is recorded by default with today's date. The round button at the start of the entry row shows the current day, and clicking it opens a calendar to pick another date — including past months.
Why the date matters so much: it determines which month the action belongs to, and therefore also when it appears in the table and in which monthly balance it is counted. The maaser obligation, by contrast, is computed from all dates together — as explained in the section on the main screen.
When you turn on the Hebrew calendar (☰ → ⚙️ System Settings → 🎨 General), all the dates in the system are shown in full Hebrew with gematria letters — for example ט״ו בתמוז תשפ״ו — in the tables, in the calendar icons and in the date picker.
In fields where you enter a day of the month (in recurring actions) you can type either digits or letters — 15 or ט״ו — and both forms are recognized automatically.
⚠️ The data itself is always stored by the Gregorian calendar. The Hebrew calendar is a display layer only, so you can switch back and forth between the two without changing anything in the data.
Recurring actions save you from repeated manual entry. Instead of entering a fixed salary, a fixed donation or a fixed expense each month, you define them once, and the system reminds you and records them for you automatically every month.
Where do you set them up? In the main menu (☰) → Day-to-Day → 📅 Recurring Actions.
Three types: you can define a fixed income, a fixed expense (of the income-offsetting kind explained above) or a fixed maaser set-aside.
For each recurring action you can choose separately whether its "day of the month" is counted by the Gregorian calendar (a fixed day every calendar month) or the Hebrew calendar (a fixed day every Hebrew month, for example always Rosh Chodesh).
The "📅 Pending recurring actions" window: each time you enter the system, if a recurring action has come due, a window appears gathering all the pending actions (even if you have not been in for a while — the system fills in all the months that passed). The choice is per action:
Changing an amount before recording: in each row the amount can be edited directly in the window — useful when this month's amount differs from the usual (an addition, a deduction or an update).
The three bottom buttons operate on the whole list together: ✅ Confirm carries out what is marked in each row, ⏰ Defer all defers them all to next time, and ✖ Do not record skips them all. 💡 Closing the window with ✕ also defers everything, so nothing is recorded by mistake.
💡 In mortgage or loan rows there is no amount editing and no defer button, because the amount is not a value of yours but the interest component the system calculated for that month.
Note: this is not a default. For the deferral to work, you must first turn it on: ☰ → ⚙️ System Settings → 🎨 General → "Defer an action falling on Shabbat or a Jewish holiday".
Once on: a recurring action (fixed income, expense, maaser or chomesh) whose recording date falls on Shabbat or a Jewish holiday on which the banks are closed is deferred automatically to the next business day after it.
The deferred dates: Rosh Hashanah (1–2 Tishrei), Yom Kippur (10 Tishrei), Sukkot (15 Tishrei), Shemini Atzeret & Simchat Torah (22 Tishrei), Pesach (15 Nisan), the seventh day of Pesach (21 Nisan) and Shavuot (6 Sivan).
💡 Mortgages have their own dedicated scheduled mechanism (🏦 Recurring Mortgage), explained in the next section.
The mortgage topic is too broad to fit into one section, so it has a separate, full guide — halachic background, practical explanation and examples. It is not here but inside the mortgage window itself:
Or simply click here to open it now.
Automatic calculation: a mortgage payment is made of principal and interest. The system works out by itself which part of the payment is interest, and since interest is an expense that reduces the profit — it is entered automatically into the income column under a maaser-exempt classification.
Supported mortgage types:
💡 The full halachic background is in the Mortgage calculation guide — click here to open it. The practical step — how to fill it in, field by field — is in the guided walkthrough (🎓 from the mortgage window), not here.
This is one of the most powerful tools in the system: just upload an Excel file or a bank/credit statement, and the system reads all the transactions automatically from the file and moves them into a draft screen. All that's left for you to do is go over the draft and mark each transaction's type.
1. Column mapping (once): you simply tell the system which column in the file is the date, which is the description and which is the amount. The amount can be a single column with plus/minus, or separate credit and debit columns — and the system handles both.
2. The draft screen — where the main work is: all the transactions from the file appear together in one list, and the system has already read them for you. Beside each transaction are three checkboxes — income / expense / maaser — and you simply mark for each which one it is. Only the rows you mark are taken in.
📅 Date format: make sure the date column in the file is a real date and not text. If it is text — save it in the format day/month/year (for example 09/06/26 = June 9th), to avoid confusion between day and month.
The 📊 Budget management section of the menu (☰) gathers the tools for managing several accounts in one system: 🗂️ Manage sheets, 🏷️ Tags, 🔍 Search all sheets and 🎓 Visual guides — on-screen guided walkthroughs for the budget-management topics.
🗂️ Multiple sheets: you can manage several separate sheets (e.g. "Main", "Business", "Family") — each sheet has its own income, expenses and balance, its own color, and a switching tab at the bottom of the screen. Creating, editing and deleting sheets — via menu → 📊 Budget management → 🗂️ Manage sheets. The create window asks for a name, color and currency — and for the maaser method 👇
🌊 Shared maaser or fully separate: either way income, expenses and the balance are managed separately per sheet — the only difference is the maaser/chomesh calculation: "two fully separate accounts" — each sheet has its own maaser account, and charity given in one sheet does not reduce the debt in another; "shared maaser only" — maaser is calculated from all the income of the shared-maaser sheets together, the same single debt is shown in all of them, and charity is recorded once and reduces it in all of them. A live demo of the difference — in the "🗂️ Sheets" walkthrough under 🎓 Visual guides.
📊 Rate and currency per sheet: in the sheet editor (✏️) you set each sheet its own set-aside rate (default 10%) — useful when the business sets aside a different rate, or when there are profit-sharing partners and you set aside only on your share; in shared maaser each sheet contributes to the debt at its own rate. Each sheet can also run in its own currency, with no conversion — but a sheet in a currency different from the main one cannot join shared maaser (shared maaser is possible only between sheets in the same currency).
🏷️ Tags: group actions, and set for each tag whether it is included in the maaser calculation or not — so the same system manages both maaser and a household budget. Tags are separate per sheet (when creating a sheet you can copy them from the current one). Full details — in the "🏠 Tags and household-budget management" section below.
🔍 Search all sheets: a search window that goes over all sheets together — filter by description, exact amount, date range or type (income / expense / maaser / chomesh); results are grouped per sheet with subtotals, an overall summary from all sheets at the top, and everything can be exported to Excel.
💾 Backup: the backup always includes all sheets together.
Beyond the maaser calculation, you can manage your household budget in the same system — all your everyday income and expenses — without affecting the maaser calculation. The tool for this is the tags system: you mark for each group of actions whether it is included in the maaser calculation or not.
The full explanation — how to create tags, split the calculation, and use a "not counted for maaser" tag to build the household budget — is gathered in the dedicated tags guide:
Intended for someone who has occasional income in a foreign currency (dollars), while all the rest of the activity is in shekels. The feature is off by default, so someone working only in shekels sees no addition in the interface.
In the table the row shows the shekel amount, and beneath it in small text the source — for example $100 · rate 3.70 — for full transparency.
💡 The rate is set by you as you choose, and can be adjusted to your set-aside custom. After each record the toggle returns automatically to ₪, so dollar income is not recorded by mistake.
When editing a dollar row — if you change the shekel amount, the row becomes an ordinary shekel row (the dollar marking is removed), to prevent a mismatch.
All the system's appearance settings are gathered in one place: main menu (☰) → ⚙️ System Settings → 🎨 General.
💡 In the system's initial welcome window too you can directly choose a preferred appearance and calendar.
🔍 The AAA (zoom) button: in the top bar, changes the text size in the system for a perfect fit to your screen — especially for users with browser zoom (150%) on the computer.
Clicking "🔎 Filter & reports" in the top bar opens a search bar that unfolds below the bar, across the full width of the screen. This way the tables always stay fully visible, even while filtering.
Closing: click "🔎 Filter & reports" again, or the ✖ inside the bar. Closing the bar does not clear the filter itself — the tables will keep showing only what was filtered until you click "Clear".
Before talking about backup, it's worth first understanding where and how the system stores your data in the first place — so you know exactly what the backup is protecting you from.
The system saves all the data automatically as a real file on your computer, even without any backup setup — on every addition, edit or deletion of an action, immediately and by itself, with no need to click "save" and no action at all on your part.
In addition, the system keeps the last 3 versions of this data file by itself — an extra internal safety net (for example if a particular file becomes corrupted). This is an internal-only protection layer, belonging to that same computer.
The data is saved automatically, immediately and by itself, on every action you perform — but not as a standalone file on the computer, rather in the browser's own local storage (localStorage), depending on the specific browser.
This storage is erased if: you move to another browser or browsing profile, clear the site's "Cookies and Site Data", or reinstall the browser. There is no automatic file on the computer here.
Because of this dependency on the specific browser, in the browser version the backup is not merely recommended — it is essential.
🛡️ So what is the backup? The backup is a separate safety layer — a full copy of all the data, saved as a file in a folder you choose. There are two kinds:
With the two layers together — the ongoing storage (a file on the computer, or localStorage in the browser) and the backup in a separate folder — your data is well protected even in the event of a malfunction, an accidental deletion, or a move to another computer/browser.
Over the years thousands of rows accumulate. If you want to trim the lists, there is a dedicated tool for it: ☰ → 🧹 Open the archive-clearing screen.
You choose a date range (from / to), click 🗑️ Delete and confirm — and all the actions in the range will be deleted, from both the income table and the maaser table.
⚠️ Note before using this: the deletion is final and cannot be undone, and it changes the maaser-obligation calculation — deleting old income reduces the obligation, and deleting old set-asides increases it. Use it only after you understand the effect, and preferably after a backup.
For each action you can choose whether its "day of the month" is counted by the Gregorian calendar or the Hebrew calendar.
How maaser is calculated on an income-producing property — the halachic background
Calculating maaser on a mortgage is the most complex topic in the app: it involves both a halachic ruling and banking terms that are easy to mix up. It's worth reading this guide once, straight through, at a relaxed pace — the data entry itself, once you understand it, takes only a few minutes.
Prefer to see it before you read? There's also a concise guided walkthrough that demonstrates the whole process on screen itself, with sample data that is deleted when it finishes.
A mortgage taken for an income-producing property (a rental housing unit) gives rise to two common mistakes in the maaser calculation. The guidance below is based on rulings from leading rabbis at halachic-guidance institutions.
Some hold that nothing should be set aside from the rent, on the thinking that taking the mortgage was the expense, and the monthly payment is simply repaying that expense. But this is a mistake: the loan itself is not an expense at all — it is an exchange. The bank gave you money, and you exchanged it for an apartment; the money did not "go" anywhere — it changed form from cash to an asset. It cannot be that the whole time you are "repaying an expense," and at the end you are left holding an entire apartment of your own — an expense, by definition, leaves no asset behind. (A genuine expense that IS offset is furniture or consumable equipment in the housing unit — such as an oven, a refrigerator, etc. — which wears out and is replaced every few years.)
Some offset nothing and set aside from the entire rent. But the monthly payment splits into principal and interest, and the two components are treated differently.
Set aside from the rent, but offset only the interest. The principal counts as income — in exchange for it you purchase more of the asset, so it is not offset. The interest is an addition to the cost of the asset, so it counts as an expense that is not subject to maaser and is offset against the income.
The halachic framework of heter iska arrives at exactly the same calculation from a different angle — the interest is the share of the profit taken by the bank as a partner in the transaction, and is therefore offset.
Record the rent in the income column. Each month the app automatically calculates how much of the payment is interest, and records that amount as an expense exempt from maaser. Even with a fixed monthly payment, the ratio between principal and interest changes from month to month — and the app knows this and updates accordingly.
Here the basic rule gets refined: when the mortgage was not taken entirely for the investment, the interest is not offset in full either. This is handled through the Partial (%) field.
This part is only for someone whose income-producing property is part of their own home — for example a housing unit built within or below the house (in the US, typically a basement unit), where the mortgage on it also served private needs.
If your property is entirely separate from your home — a different apartment, a different building, a property bought purely for investment — there is nothing to calculate here: the Partial (%) field stays at 100%, and all the interest is offset.
Someone taking a mortgage for a housing unit cannot always offset all the interest, since not the entire mortgage was taken for the investment — part of it may have gone toward renovating the home itself. So you need to estimate what percentage of the mortgage was taken for the housing unit, and that is what you fill into the Partial (%) field. Only that percentage of the interest will be offset.
It is recommended to consult a rabbi knowledgeable in this area on how to calculate the split between renovating the home and the housing unit, particularly in these cases:
Sometimes, even if the home renovation cost (say) 30% of the mortgage, it may still be possible to offset all of the interest. This is a complex matter that should be decided with a rabbi — and the value you enter in "Partial" is what determines how much interest is actually offset.
From here on it is pure operation: what to enter in each field, what the system does with it, and how to verify the data is accurate. The topics follow the order of the work — click a topic to open it.
This is the first decision, and it is simple:
You enter static data only (balance, annual rate, months remaining). Everything else is automatic:
The system analyzes and computes the upcoming mortgage payment for you (principal and interest together), and automatically separates out the interest component each month — the part that is offset for maaser purposes.
On the payment date the system automatically records only the interest component as an expense in the income manager. The principal component is not recorded (as explained in the halachic background — the principal is income that is not offset), which also prevents double-counting against the rental income already recorded.
This is the most critical point for understanding the calculation. In a Spitzer track the amount taken by the bank is identical every month — and yet its internal split changes month by month. Here is the קל"צ track from the example (a fixed 1,649.89, over 240 months):
There is no need to dig up the original mortgage documents — in fact, it is better not to. All the data you need is in the personal area of the bank's website, on the mortgage page: it lists all the (sub-)tracks that make up the mortgage, each on its own row. Each track on the bank's site = one track in the system (the "➕ Add track" button), and for each track you copy three figures:
All three figures must be current as of the moment you enter them. If you enter the original amount and the original number of months from the day the mortgage was taken, the system will split principal and interest incorrectly — and as a result the interest offset for maaser will come out wrong too.
Right after entering, it is worth running the verification check at the end of this part: it reveals within a second whether anything was entered incorrectly.
| Field | What to fill in | In the example |
|---|---|---|
| Name | Any identifying name, so you can spot it in the list | Apartment mortgage |
| Charge day | The day of the month the payment actually leaves the bank account | 10 |
| Partial (%) | What percentage of the mortgage was taken for the investment. The default is 100%, which fits most cases — meaning all the interest is offset | 100 |
💡 When would it be less than 100%? Only when part of the mortgage was taken for private needs (for example, renovating your own home). This is a complex matter to decide with a rabbi — the full explanation is here in the "Housing unit within the home" part ↑.
Each track on the bank's site = one track in the system (the "➕ Add track" button). This is what our example looks like:
| Field | Track 1 | Track 2 | Track 3 |
|---|---|---|---|
| Track name | Fixed | Prime | Variable |
| Opening balance | 250,000 | 250,000 | 300,000 |
| Interest type | קל"צ | Prime | מל"צ |
| Annual rate (%) | 5 | — computed automatically — | 4.5 |
| Prime rate (%) | — | 5 | — |
| Margin from prime (%) | — | -0.5 | — |
| Months to finish | 240 | 360 | 360 |
| Calculation type | Spitzer | Spitzer | Spitzer |
| ↳ Monthly payment | 1,649.89 | 1,266.71 | 1,520.06 |
✔ The verification check: the last row is not entered — the system computes it by itself. The three tracks add up to 4,436.66, and that is exactly the amount that should leave the bank account. If the numbers match — the entry is accurate.
💡 Note that the prime track and the מל"צ track both stand at 4.5%, and yet they are completely different: the first will change following a Bank of Israel decision, the second only when its pre-set change point arrives. The interest type — not the percentage — is what determines when the rate will move.
💡 The three figures (balance, rate, months remaining) come from the personal area of the bank's website, on the mortgage page — not from the original loan documents. More in "where do the numbers come from" ↑.
"Prime" is not a number your bank invented, nor something set in negotiation. It is a single number, identical in every bank in Israel, and it is always:
That 1.5% never moves. So any change in prime comes from one place only: a Bank of Israel rate decision.
If prime is the same for everyone, what was actually set in your agreement? The margin — how much you pay above or below prime. It is a number fixed for the entire life of the loan, and it never changes. You know it from the sentence they told you at the bank: "prime minus a half", "prime plus one percent".
In the Loan margin from prime (%) field you fill in exactly that number — with its sign:
| What was agreed at the bank | What to fill in | The actual rate |
|---|---|---|
| Prime minus 0.5% (P-0.5) | -0.5 | 5% + (-0.5%) = 4.5% |
| Exactly prime (P) | 0 | 5% + 0% = 5% |
| Prime plus 1% (P+1) | 1 | 5% + 1% = 6% |
⚠️ The rule to remember: after the initial entry, never touch the margin again. When prime changes you update only the "Prime rate" field. The system adds the two together by itself — and the "Annual rate" field fills in automatically.
If the mortgage is split across different rates, choose recurring mortgage and add a separate (sub-)track for each part — the system sums them all together. (For the Partial (%) field — see the "Housing unit within the home" part above.)
The first sign always comes from the bank account: if this month's charge differs from last month's, it is almost always a sign the rate has changed — and it is time to update the system.
So that you do not have to remember on your own, the system knows the official calendar on which the Bank of Israel publishes its rate decisions. Turn on the 🔔 Enable a prime-rate check reminder switch inside the track, and from that moment:
With variable rates it is easy to forget to update the change in the system, so an automatic reminder can be enabled per track:
On every reminder you can confirm "Updated" — and the next date is set automatically.
Every track has a small ➕ button under "Changes during the month". It lets you record an event on a specific date, and the calculation updates from that date only. In a regular (Spitzer) track the list offers three options: rate change, loan repayment — shortening the period, or loan repayment — reducing the monthly payment. The two repayment options are not the same: the bank does one of the two after a partial repayment, and a wrong choice here distorts the principal/interest split for the rest of the loan — and therefore the maaser too. There is no "mortgage increase" here, simply because no such thing exists: additional money is a new loan. (In a balloon or overdraft-facility track the list differs and includes a withdrawal too, since there is no fixed monthly payment there.)
Repaid a large amount, enlarged the loan, or had the rate change on a specific date? Inside every track there is ➕ Add change — pick a date, an action type and an amount, and the calculation updates from that date only.
💡 No separate save is needed per change — everything is saved together with the "💾 Save" button at the bottom of the window.
Add up the amounts shown in the "Expected payment for the coming charge" box of all the loans in the mortgage, and check whether the total equals the amount actually leaving the bank account. If it does — the entry is accurate.
🛡️ Time to back up
A week has passed since the last backup.
The system will map the columns automatically and move them to the draft.