Source: https://oguzerol.com/en/daily-income-expense-tracking-app/

[![Example scenario: a card receipt is corrected, the earlier amount stays in the record, and the day-end summary waits for approval.](https://oguzerol.com/gorseller/senaryo/daily-income-expense-tracking-app-senaryo-en.webp)

View full size](https://oguzerol.com/gorseller/senaryo/daily-income-expense-tracking-app-senaryo-en.webp)

# Daily Income and Expense Tracking with End-of-Day Cash-Up: Who Clears the Difference?

[Oğuz Erol](https://oguzerol.com/en/about-me/)  |  24 min read

A daily income and expense tracking app is a web app where every point of sale records the day’s cash, card, transfer and expense entries in one structure. At closing, the till is counted and compared with the records, and any difference keeps an undeletable line saying who approved it and why. I build these apps for companies. The problem is not only the difference itself. It is a difference that slips unapproved into the next day’s till, because then head office stops trusting the numbers branches send.

The cashier cannot clear a difference; the person who approves the reason in writing does. In my suggested set-up a difference within ±20 clears automatically and is recorded, one between 20 and 250 clears with the store manager’s approval and a stated reason, and one above 250 goes to head-office review after a second count. A difference with no found cause is cleared by nobody: it stays on head office’s open list.

Below I follow one week at a fictional six-store hardware chain: 36 cash-ups, three large differences, two of them explained, and one decision. Store B’s unexplained difference for the week is 1,080; across the other five stores the weekly unexplained differences add up to 90 regardless of sign, and the largest is 35. The finance lead changes the till routine, not a person.

This page covers daily recording and the end-of-day cash-up. When card takings actually reach the bank, and at what fee, belongs to [bank and card terminal reconciliation](https://oguzerol.com/en/bank-transaction-reconciliation-app/).

Transfers between branches, cover arrangements and the branch side of day locking belong to the [branch-based data entry system](https://oguzerol.com/en/branch-based-data-entry-system/).

## Which items does the daily record hold?

The daily record should hold every money movement of the day: into the till, out of it, or never touching it. Most tills produce a **Z report** at day end (a Z read in some countries): the day’s recorded sales total, after which the device resets. Each item below affects the drawer differently.

| item | where it comes from | changes cash in the drawer? | proof |
| --- | --- | --- | --- |
| Cash sales rung through the till | Z total minus card and other tender inside Z (see my assumptions below) | Increases | Z report |
| Card sales | Card terminal end-of-day report | No | Terminal end-of-day slip |
| Card takings outside Z | Invoiced card sales, tips left on card | No (in the terminal total, not in Z) | Invoice, terminal slip |
| Other tender | Meal vouchers, gift cards, sales put on account or on a room bill at the till | No | Separate terminal report or voucher count; tender breakdown if your device gives one |
| Cash in outside Z | An invoice paid in cash on the spot, cash tips put in the drawer | Increases | Invoice, tip record |
| Sales paid by bank transfer | Invoice and the customer’s payment notice | No | Invoice, bank line |
| Cash received on account | A trade customer paying an earlier credit sale in cash | Increases | Receipt |
| Cash paid out | Courier, water, small purchases; tips paid out to staff in cash (“tip payout” sub-line) | Decreases | Receipt photo, tip payout record |
| Cash refunds outside the till | Money handed back against a refund document | Decreases | Refund document |
| Banked during the day | Cash deposited during the day | Decreases | Deposit slip |
| Opening float | The same amount of change every morning (a till bank in US usage) | Fixed | Previous day’s cash-up |

**Expected cash** is the opening float plus cash sales rung through the till, cash in outside Z and cash received on account, minus cash paid out, refunds outside the till and cash banked during the day. The **cash difference** is counted cash minus expected cash. A difference with a found cause is an **explained difference**; one without is an **unexplained difference**.

**My design assumptions (all three are checked with your accountant in the first step):**

1. I could not confirm from a primary source that a Z report splits tender types. So card takings come from the terminal report, other tender from separate terminal reports or a voucher count, and cash sales = “Z total − (terminal total − card takings outside Z) − other tender”. Meal vouchers that run through the bank terminal are not deducted again.
2. I assume invoiced cash sales do not appear in the Z total.
3. I assume a refund through the till is already deducted from the Z total. If your report shows refunds separately, the refund column and the formula change.

If your device reports tender types separately, the calculation comes straight from there; I check your device’s output in the first step.

A refund through the till has already lowered the Z total if your device reports it net; entering it again on a refund line would distort the difference the other way. So the app asks “through the till or by hand?” and only a by-hand refund becomes a separate line.

A Z-total mismatch and a cash difference are separate warnings. If you also have a sales system, its daily total is compared with Z; a mismatch there is a record problem, a short drawer is a cash problem, and one red cell for both hides which broke. Without a separate sales record this warning is not set up.

Transfer-paid sales and expenses paid by card or transfer never enter the till, but they appear in the daily summary. Whether the money moved is for bank reconciliation to confirm.

**Restaurants, cafés and hotel front desks change the table.** Meal vouchers and delivery-platform payments are never expected as cash in the drawer. A card tip sits in the terminal total but not in Z, so it goes under card takings outside Z; a cash tip put in the drawer goes under cash in outside Z, and a tip paid out to staff under cash paid out (“tip payout”). When waiters or couriers hand in cash collected at the table or the door, each hand-in is a “cash received” line against that person, not added to expected cash twice. A hotel room charge comes from the guest folio, never the till. Where trading runs past midnight, the trading day runs from first opening to the last Z report.

## If you are in Turkey

In Turkey the Z report is also a statutory daily record from the registered cash register, so the app will not approve a cash-up without one. Receipt numbers may restart each day, so a cash-up is keyed on store, device serial, date and Z number. The legislation, its Official Gazette sources and my amendment-check caveat are on the [Turkish version of this page](https://oguzerol.com/gunluk-gelir-gider-takip-uygulamasi/).

## A sample week: six stores, 36 cash-ups

*Sample data, fictional.* A hardware and building supplies chain has six stores and a two-person finance team. Stores open six days a week, each with one drawer and one cash-up a day: 6 × 6 = 36 cash-ups. In the app, each day starts with an opening float of 2,000. Some customers are tradespeople who pay by transfer or settle their account in cash. Today each store fills in its own spreadsheet tab. Each tab opens the next day with the previous day’s counted cash, so a difference quietly carries over. Amounts are in an unnamed local currency.

With the thresholds from my suggested rules below, the 36 cash-ups fell like this:

| outcome | cash-ups | what happened |
| --- | --- | --- |
| Zero difference | 22 | Cashier counted, store manager approved |
| Within ±20 | 6 | Closed automatically, recorded; net −35 |
| 20 to 250, explained | 2 | Store D’s missing courier receipt (−180), Store F’s tea and water without a receipt (−60); approved and closed |
| 20 to 250, unexplained | 3 | Store B −90 and −140, Store A +45; the manager approved, but they stayed open on head office’s list |
| Above 250 | 3 | Second count, review by head-office finance |
| **Total** | **36** | **6 stores × 6 days** |

### One cash-up, line by line: Store C, day 2

**The order of a blind count:** the cashier counts the drawer note by note and saves the count first; it locks. Only then come the Z total, terminal total, expenses and deposits, and the expected amount appears. Reverse the order and the cashier can work out the expected figure in their head. If one person counts and another keys the entries, the order does not matter.

My suggestion: produce the Z report and terminal slip after the count too, or keep the slips with the manager until the count is locked; if the cashier holds them, the count is blind only to the screen. The count locks through a “lock the count” confirmation. After that, a wrongly keyed count is not deleted: the right figure goes in as a correction entry on a separate line, and the second count required above 250 is such a line.

| step | line | amount |
| --- | --- | --- |
| 1 | **Counted cash (locked)** | **3,730** |
| 2 | Opening float | 2,000 |
| 3 | Z report total | 61,700 |
| 4 | Card terminal end-of-day total | 45,100 |
| 5 | Card takings outside Z (invoiced card sales) | 1,800 |
| 6 | Other tender | 0 |
| 7 | Cash sales rung through the till (61,700 − (45,100 − 1,800) − 0) | 18,400 |
| 8 | Cash in outside Z, cash received on account | 0 |
| 9 | Cash paid out (courier 350 + water 120) | 470 |
| 10 | Refunds outside the till | 0 |
| 11 | Banked during the day | 15,000 |
| 12 | **Expected cash** (2,000 + 18,400 − 470 − 15,000) | **4,930** |
| 13 | **Cash difference** (3,730 − 4,930) | **−1,200** |
| 14 | Closing hand-over (3,730 − 2,000), banked next morning with a slip | 1,730 |
| — | *Info: invoiced sales paid by transfer* | *12,500 (never in the till)* |

Because the difference was above 250, the store manager counted again: same result. Next morning the cause turned up: a 1,200 refund handed over by hand against a refund document, outside the till, never entered. The locked day got a correction entry with the document photo, approved by head-office finance rather than the store manager, and the difference cleared. The next day the drawer opened with 2,000 again.

### The other two large differences

- **Store E, day 4: +600.** The till was over. A trade customer had paid 600 off his account in cash; the cashier put the money in the drawer but did not enter the receipt. Once the receipt was entered, the difference cleared. A till that is over is also a problem: if nobody finds the cause, a customer’s account stays wrong.
- **Store B, day 5: −850.** The Z total that day included an 800 gift card. It had already been deducted as other tender; the −850 had no numerical link to it. The second count gave the same figure, and nothing was missing from expenses, refunds or account receipts. It was recorded as an unexplained difference.

### Weekly summary and the decision

| store | cash sales | card sales | transfer | cash expenses | unexplained difference |
| --- | --- | --- | --- | --- | --- |
| A | 96,400 | 212,800 | 64,000 | 2,310 | +35 |
| B | 88,900 | 190,500 | 41,200 | 1,940 | **−1,080** |
| C | 104,700 | 241,300 | 72,500 | 2,650 | +15 |
| D | 71,200 | 158,600 | 38,900 | 1,720 | −25 |
| E | 92,300 | 201,400 | 55,800 | 2,080 | −15 |
| F | 63,500 | 139,700 | 29,600 | 1,390 | 0 |
| **Total** | **517,000** | **1,144,300** | **302,000** | **12,090** | **−1,070** |

*Card sales are terminal totals, including invoiced card sales. Cash expenses include receipts found later. The unexplained column includes differences within ±20. Store C’s 1,200 refund sits on its own line.*

Store B had an unexplained difference three times: −90 on day 1, −140 on day 3 and −850 on day 5, 1,080 in all and about 1.2% of B’s weekly cash sales; the point is the repetition. The first two were separate lines on head office’s list until day 5, when the repeat rule fired and the app set the three side by side. All three fell on days when two cashiers handed one drawer over at the midday shift change without counting, because the cash-up unit was the day. The finance lead blamed no one: at B the unit became drawer × shift, with a blind count and two-person approval at every hand-over. Review rule (my suggestion): if no unexplained difference above ±20 appears at B within two weeks, the routine stays; if one does, the count extends to refund and expense entries within the shift.

In B’s current spreadsheet tab this decision would not have surfaced: the tab opens the next day with the counted cash, so −90 and −140 melt into the next day’s till and only −850 shows, which reads as bad luck. With the layout I suggest below (fixed float, one row per cash-up), filtering column O for Store B shows all three. The weakness was the carry-over in the old tab, not the spreadsheet. What the app adds is the audit trail and the lock: a difference cannot be changed quietly afterwards, and every correction carries who approved it.

The summary has only these six columns. The most common dashboard mistake I see is trying to put every figure on the dashboard; then Store B’s row disappears in the crowd.

## End-of-day rules: my suggestion

The thresholds and times below are my starting suggestion, adjusted with the first month’s data. Set thresholds as a share of daily cash sales: in the example an average store takes about 14,360 in cash a day, so ±20 is roughly 0.14% and 250 roughly 1.7%. At a site taking 3,000 a day in cash, the same shares give about ±4 and 50.

| rule | my suggestion | what it prevents |
| --- | --- | --- |
| Cash-up unit | Drawer × shift; at a single-shift, single-drawer site, the day. The day’s cash-up is the sum of its shifts | Nobody knowing whose till it was at hand-over |
| Two-person count | The cashier counts; a second person (store manager or supervisor) is present and approves from their own account | A cash-up resting on “I counted, it balanced” |
| One person on shift | The count is still blind and a photo of the drawer is attached. The second approval comes next morning from the store manager or head office; until then the cash-up stays “awaiting second approval” | The rule lapsing because nobody else is there |
| Blind count | The count is saved and locked before Z, terminal and expense entries (or counted and keyed by different people). Z and terminal slips are not handed to the cashier until the count is locked. The expected amount appears afterwards. Any correction or second count after the lock is a separate line | Counts drifting towards the expected figure |
| Difference threshold | ±20 closes automatically but is recorded. Between 20 and 250, “explained” or “unexplained” is chosen and the store manager approves either; an unexplained one does not close but goes onto head office’s open list. Above 250 needs a second count and head-office review | Wasted time on small differences, silence on large ones, unexplained differences that look closed |
| Repeat rule | A third difference above ±20 at the same drawer in one week, explained or not, goes to head office for pattern review regardless of amount. Single differences already sit on the open list; this rule sets them side by side. Differences within ±20 that cleared automatically do not count | Recurring differences each looking acceptable alone and each treated as handled |
| Nobody approves their own cash-up | The store manager approves the cashier’s cash-up. If the manager closed the till, head office approves | The person who made the error clearing it |
| Locking | An approved cash-up is locked and cannot be overwritten. One not approved by noon on the next working day goes to head office as “unapproved” | Past days changing silently, forgotten approvals |
| Correction entry | A correction to a locked day is a separate line with a reason and document. The old line is never deleted. It is approved one level above whoever approved the cash-up | Corrections without a trail |
| Closing hand-over and float top-up | After the count, cash above the float leaves on a “closing hand-over” line. If the float is short, head office tops it up on a separate “float top-up” line | A shortage being quietly cleared by a top-up |
| Differences do not carry over | A day’s difference is not evened out in the next day’s till. The next day starts with the same float | Store B’s two smaller differences disappearing |

## Where does an unexplained difference go?

The app does not clear the difference; it records it. An unexplained difference stays open on head office’s list with the site, day, shift, counter and approver. How it is booked is your accountant’s decision; the app hands them the list with reasons and documents.

## Who does what, and how is the audit trail kept?

| action | cashier | store manager | head-office finance | owner / finance director | auditor |
| --- | --- | --- | --- | --- | --- |
| Enters sales, expenses, receipts, refunds | ✓ (own till) | ✓ (own store) | — | — | — |
| Does the blind count | ✓ | ✓ (own till) | — | — | — |
| Approves the cash-up | — | ✓ (someone else’s) | ✓ (the manager’s) | — | — |
| Requests / approves a correction to a locked day | requests | requests | approves | — | — |
| Changes thresholds and rules | — | — | proposes | ✓ | — |
| Sees all stores, exports | — | own store only | ✓ | ✓ | ✓ (read-only) |

The audit trail keeps an undeletable line for every change: who, when, which record, old and new value, reason. “Why did Store C’s day 2 change?” is answered on one screen: a 1,200 refund, the document photo, who requested and approved it. The app makes the reason and the higher approval mandatory fields.

## What does AI do, and where does it stop?

AI makes suggestions in this app; it does not produce numbers. Expected cash, the difference and the weekly totals come from the app’s own calculation, and a person approves. It helps in three places:

1. **Category suggestions from receipts and notes.** The cashier photographs an expense receipt. The model reads amount, date and supplier, fills in the entry and suggests a category such as courier, water or small purchase. For an expense without a receipt, it suggests one from the cashier’s note. Nothing is saved until the cashier confirms.
2. **Reading the Z report photo.** The photo can be of a printed report or the device screen. If the Z total the cashier typed differs from the amount read from the photo, a yellow warning appears. The cashier decides which is right; the model does not choose.
3. **Pattern flags.** When the repeat rule fires, the model writes what the differences share into the summary note: “At B, all three unexplained differences fell on days when the midday hand-over was not counted.” It talks about store, shift and drawer, not named people. The finance lead decides.

No row reaches the model before the permission filter, and a store manager’s answer only mentions their own store. A cashier’s name next to a cash difference is personal data, so I suggest sending a cashier code; a code is a pseudonym and does not make the data anonymous. If you operate in the EU or UK, sending personal data to an AI service abroad falls under the GDPR’s international transfer rules (Chapter V); other countries have their own. I don’t give legal advice. I put in writing which fields reach the model in the first step’s output, and your legal adviser assesses it.

## Where exactly do spreadsheets struggle?

In my Google Ads Keyword Planner check on 15 October 2026 (average monthly searches over the last 12 months), “cash up sheet” had about 170 in the UK and 10 in the US; in the US “cash count sheet” had 480.

If you stay in a spreadsheet, here is the layout I suggest. One table, one row per store per cash-up. Columns: A Date, B Store, C Opening float, D Z total, E Terminal card total, F Card takings outside Z (invoiced card sales, card tips), G Other tender, H Cash in outside Z (invoiced cash sales, cash tips put in the drawer), I Cash received on account, J Cash paid out (expenses, tip payouts), K Refunds outside the till, L Banked during the day, M Expected cash, N Counted cash, O Difference. Formulas:

- `M2: =C2+(D2-(E2-F2)-G2)+H2+I2-J2-K2-L2`
- `O2: =N2-M2`

The closing hand-over (N − C) and any float top-up are two separate lines you write by hand in the spreadsheet.

| cash-up | D | E | F | G | I | J | K | L | M (expected) | N (counted) | O (difference) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C, day 2 | 61,700 | 45,100 | 1,800 | 0 | 0 | 470 | 0 | 15,000 | 4,930 | 3,730 | −1,200 |
| C, after correction | 61,700 | 45,100 | 1,800 | 0 | 0 | 470 | 1,200 | 15,000 | 3,730 | 3,730 | 0 |

*In both rows C (opening float) is 2,000 and H (cash in outside Z) is 0.*

Store E’s day 4 (+600, then zero with the receipt) and Store B’s day 5 (−850, gift card in column G) passed the same formula in a script. So did tips: a 600 card tip paid out in cash (600 each in E, F and J) leaves the difference at zero, and a 300 cash tip put in the drawer and paid out cancels between H and J.

As stores and cashiers multiply, this layout comes under strain in specific places:

- **A blind count is hard in a single table.** Whoever types the count sees column M on the same row. A separate form and a locked sheet can do it, but the order and the lock depend on people’s discipline.
- **Two-person approval is a typed name.** With signed-in sharing, version history shows who made a change (general behaviour of Excel and Google Sheets as of 15 October 2026; check your version), but the sheet does not enforce “nobody approves their own cash-up”.
- **Locking a closed day is possible but needs upkeep.** Someone has to set protected ranges, and the reason and higher approval need a separate routine.
- **Differences can carry over.** If the next day’s float is taken from the previous day’s count, the difference moves silently into the new day.
- **Documents live elsewhere.** Receipt and Z photos sit in a messaging group, not attached to the row.

In the app, the rule you define is applied while the cashier enters the count, not when someone looks at the sheet at month-end.

## When your accounting or POS software is enough

I would not suggest a separate app if:

- You have one site and the owner cashes up personally. The spreadsheet layout above is enough.
- Your accounting or point-of-sale software already has per-cashier cash-ups, a count and an approval step, and your team uses it. Use that fully first.
- Your stores take almost no cash. Then the real job is bank reconciliation, not counting tills.

Formal records stay in your accounting system; the app hands accounting a checked day.

## How do we start, who owns the data and code, and how do users sign in?

The first step is mapping how you work today: a few weeks of cash sheets, Z reports and the messages where differences were discussed. In that step’s output I put in writing:

- an end-of-day rules table with your thresholds,
- a role list: who counts and who approves at each site, who approves corrections at head office,
- the cash sales calculation built from your till’s actual report,
- the scope of the first version.

The most common mistake I see in automation projects is choosing the most complex process for the first automation. So the order is:

1. Daily entries, blind count, two-person approval, locking and audit trail, in two stores first.
2. Correction entries, thresholds, the repeat rule and the weekly summary, then all stores.
3. AI suggestions, once the rules run smoothly.

**Where is the data?** The app runs on a server (VPS) whose database holds the records; the server, keys and accounts can be opened in your company’s name. The data is yours, exportable as Excel or CSV at any time. There is no per-user licence; the cost is the server’s monthly fee and maintenance, and in a small or mid-sized team adding cashiers does not change it.

**How do users sign in?** Everyone has their own account; no shared “store password”, because two-person approval needs two accounts. I put the sign-in method and user management in writing in the first step’s output.

**Who owns the code?** The full source code sits in a repository you can access, with run instructions, a dependency list and known limits. Because the app handles cash and staff data, I assess access, security, hosting and maintenance separately at the start.

**What if your accounting software or tills change?** Records and history stay in your database; only the import and export need rebuilding, and I share that scope in writing beforehand, as I do the first version’s scope and schedule once I have seen your current setup.

Send two weeks of cash sheets, with cashier names masked, through the [contact page](https://oguzerol.com/en/contact/). In the first meeting we look at which site, which shift and which missing entry your differences come from, and fill in the end-of-day rules with your own figures.

## Frequently Asked Questions

### How do I adjust the rules for a night shift that regularly runs with one person?

The base rule for a one-person shift is in the end-of-day rules table: blind count, drawer photo, second approval next morning. For a night shift that regularly runs with one person I additionally suggest a lower difference threshold at that site and applying the repeat rule per number of shifts instead of per week. How low depends on that site’s cash volume and is set with the first month’s data.

### Does the cashier make up the shortfall?

The app makes no such decision and suggests none. Recovering a shortage from an employee is an HR and legal matter, and wage-deduction law differs by country, so ask your adviser first. The app provides the record for that conversation: which shift, which drawer, whose count, which counting routine, how many times.

### How does a site that takes foreign currency cash up, such as a hotel front desk?

Each currency is its own till line, counted in its own currency; converting foreign cash into the local till would make exchange movements look like cash differences. The daily summary shows a local-currency equivalent at the day’s rate, labelled “estimate”, with the rate chosen by your finance team. Foreign cash leaves in its own currency with a deposit slip.

### What happens to the cash-up if the internet goes down?

My suggestion: write it down as a requirement in the first step. During an outage the blind count goes on a paper sheet and is photographed; when the connection returns, the same cashier keys it in with an “entered late” label and approval follows the normal flow. Past the lock time it goes onto the “unapproved” list rather than locking itself. Whether offline working is in the first version, I put in writing in the first step’s output once I have seen your stores’ connections.

[Back to top ↑](https://oguzerol.com/en/daily-income-expense-tracking-app/#icerik)

## You may also find these useful

[Expense Receipt Tracking: Matching Card Statements to ReceiptsA web app that matches each month's corporate card statement to expense records and receipts, with a missing-receipt queue, FX and refund rules. See how.](https://oguzerol.com/en/expense-receipt-document-tracking/)[Budget vs Actual Expense Dashboard: Department Budgets, Commitments and Variance AlertsA web app that compares each department's budget with actual and committed spend and alerts the right person when a variance matters. See a worked quarter.](https://oguzerol.com/en/budget-vs-actual-expense-dashboard/)[Expense Permissions and Reporting Screen: Who Sees What, Which Report Goes to WhomLet project managers see only their project and auditors get read-only exports: a web app that scopes each expense line by role. Walk through a sample company.](https://oguzerol.com/en/expense-permissions-reporting-screen/)

[Browse all articles →](https://oguzerol.com/en/articles/)

WHAT YOU CAN ASK FOR

## How do I work?
Work-hour packages

Tell me about your business and what you need on WhatsApp or by phone; we agree on **a work block of somewhere between 5 and 40 hours** and I start doing what is needed. What you get is not a calendar window — it is net working hours spent directly on your business. I can use 40 hours working three days straight, or deliberately spread it out and finish it over a year — whatever the work calls for. I do not spend my time estimating how long something will take, I spend it doing the work; every hour I spend leaves a lasting result in your business. We keep going for as long as you find it useful.

WORK BLOCKS

## Why not monthly?
Is 40 hours a week?

On a fixed monthly fee both sides are watching the wrong thing: you watch a fixed cost, the other side watches how many more contracts like this they can line up. Working by the hour puts us both in front of the same thing — the real value of the work that got done. I know not having an upfront answer to "how much will this cost in total?" is the natural cost of this model. But instead of paying a fixed fee for months to a setup that is not producing results, you only pay for the qualified time spent on your work — and you see exactly where that time went, start to finish. That is why my clients keep coming back.

5hours300€ + VAT60€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%205-hour%20work%20block.)

10hours500€ + VAT50€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2010-hour%20work%20block.)

20hours800€ + VAT40€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2020-hour%20work%20block.)

40hours1,400€ + VAT35€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2040-hour%20work%20block.)