Sole proprietorship versus limited company

I’ve been asked this a couple of times: what’s the benefit of having limited company versus having sole proprietorship? Let’s try to compare.

Assumptions:

  • I’m assuming a one-man freelancer thing again
  • I assume that operating costs for both options are about the same. They usually may be a bit higher for a limited company.
  • Your yearly income (sales – operating expenses) is 100k€ in both options.
  • You decide to have net salary of 2500€ per month for your daily life (30000€ per year).
  • Rest of the money you want to save up for future use

Sole proprietorship

Income 100k€
Personal taxes 33500€ (estimated tax % for that yearly income is 33,5%)
Your salary 30000€
Net savings, free to use: 36500€
Total tax payed: 33500€

Limited company

Income 100k€
Gross salary paid from company 37000€
Personal taxes 6845€ (18,5%)
Company gross profit 63000€
Company tax for profit 12600€ (20%)
Company profit after tax 50400€
Maximum dividends with lowest tax%: 50400€ * 0.08 = 4032€
Tax payed from dividends: 4032 * 0.075% = 302€
Total tax payed: 19747€
Net savings, free to use: 3730€
Gross savings: 46368€

By “gross savings” I mean that the money is in the company. If you want to use it for personal purposes, you have to pay income or capital tax. Here the comparison becomes difficult because there are so many ways to use the money. But the good thing is that it won’t get taxed again if you decide to keep it inside the company.

Conclusions

My two key takeaways are:

  • With these assumptions, limited company seems to be better money wise
  • At the very least, limited company offers more flexibility to spread the income. This is useful because personal taxation is per year. You could, for example, work your ass off for a couple of years, save 200k€ for the company, then take the money away from the company gradually over years as dividends and small salaries.

I’m not 100% sure if I miss a key detail here, but roughly it should go like this. If I miss a key detail, please let me know!

Bureaucracy of running a one man limited company

So, how much extra work is actually involved in running a limited company? Before I answer that, here are the usual disclaimers:

  • The choice of the accountant (or lack thereof) has a big impact on your routines. I’m using Digitase Oy.
  • You don’t have employees
  • I haven’t yet gone through the-end-of-fiscal-year-reporting.
  • I don’t consider networking and getting new customers as “bureaucracy”

Here is the list of the non-billable chores I need to do:

  • Fill in hours to three different time reporting  systems.  😐 I update one UX-friendly system daily by mobile phone, and from there I (manually) export them to the other two, weekly or bi-weekly.
    • I think this is unavoidable if you’re working as a consultant, regardless of your employment status
    • Of course if you’re lucky you only have one or maybe two system to use
  • I have a business debit card that I use to make small purchases for the company. I immediately take a photo of the receipt and upload it to a dedicated Dropbox folder that is shared with my accountant.
  • I pay company bills in my bank’s online bank. I take a photo of the bills and upload them to the Dropbox folder.
  • When needed, I tell my payroll contact person how much I want to pay salary to myself. She calculates the tax + social security payment and sends me the invoice for paying it. And also tells me the amount that I can then transfer to my personal account.
  • At the end of each month I:
    • Send an invoice to my customer using Zervant’s electronic invoicing
    • Send a monthly report to my accountant about all the incoming payments that have arrived to my account during the month. This is just one figure basically.

My accountant has web service read access to the company’s bank account, so they do all the bookkeeping based on the Dropbox receipts and the monthly account statements. If they have questions about the receipts, they’ll ask. So far they haven’t (okay, it’s been only two months).

The amount of extra day-to-day paper work has been a positive surprise for me. After the initial hassle of setting up the company, there isn’t much stuff you need to do, at least if you’re working for one client only. Maybe one or two hours per month.

You might also want to check my previous articles, costs of running a one man limited company and osakeyhtiön perustamisesta.

 

How much does it cost to run a one man limited company?

One of the things I wondered before starting my own company was: how much does it cost to run a limited company? How does xxxx € billed to my company relate to the amount I’m getting as an employee?

To be honest I didn’t make the calculations beforehand. I just went for it. 🙂 But now I know a bit more and I can share my knowledge to whomever out there wondering about starting their own business.

Assumptions and disclaimers

  • You run a limited company (osakeyhtiö), owned 100% by you. Taxation for sole proprietors is different.
  • Your company is in Finland 🇫🇮
  • You don’t have any employees
  • I’m basing this on my experiences as an IT consultant, I’m assuming you don’t have to invest into heavy machinery or such
  • These calculations may be wrong and probably I’m missing something as I’ve run my company only a few months (please let me know if I’m missing something :))

Direct expenses

  • YEL-insurance ~200€ / month (after first 4 years this will be 250€)
    • Here we have chosen a relative small annual income for your YEL-insurance (12600 € / year).
    • This affects not only the pension you’ll some day get, but also the level of basic income in longer sick and parental leaves.
    • (For reference, YEL-insurance for 60000€/year income is roughly 1000€ / month)
  • Insurances ~30€ / month. This is where you will have variance, depends totally what kind of insurances you want to have. I have health insurance and liability insurance.
  • Book-keeping ~65€ / month. You can get it cheaper if you wanna do it yourself, but I’ve chosen to hire an accountant and have them also calculate my salaries.
  • Social security payment is roughly 1% of the salary you choose to pay yourself. So with 5000€ monthly salary this will be 50€ / month.
  • Bank stuff, business debit card and web service interface for accountant ~20€ / month.
  • Yearly financial statement done by accountant 250€ / year
  • Invoicing software (Zervant) 70€ / year
  • Total: ~400€ / month.

Indirect expenses

  • Obviously you pay for your holidays, training, and whatever time you’re not billing your customer. Don’t think that you will be billing 37,5h weeks through the year. 80% is a better guess.
  • If you get sick, you get money from Kela only after 4 days. And if you only pay minimum YEL-insurance, you’re not really getting anything.
  • There are unemployment funds, but they’re a lot more expensive than they’re for employees. I’ve chosen not to be part of those and save up some buffer instead.

Indirect benefits

  • You get to buy all kinds of gadgets like computers and phones for your company. This benefits you in two ways: 1) if the gadget is used for creating income for your company (you can be creative here), you can deduct that in your company’s taxes; 2) you can deduct the value added tax (ALV)
  • You can rent yourself a working room from your home

How much salary to pay?

So, how much do you want to pay yourself? One thing to consider here is that even for those “tax free” diviends, you will be paying roughly 27% tax. (20% company tax from the profit and then the smallest diviend tax% is 7,5%). So, I’ve thought this so that I want to pay enough so that my personal tax% is close to that 27%, perhaps a bit less. If I pay too much salary, my personal tax% will rise higher, but on the other hand I don’t want to pay too little, because then my tax% would be “too small” and I don’t reap the benefits of tax progression.

But this area is complicated, and also depends really much on your case. Maybe you want to save more for the company? Maybe you’re investing the money you’re saving up for the company?

Conclusion

For me, the biggest benefits of running a limited company are the ability to control how much salary you pay yourself and the possibility to buy all kinds of stuff for the company. After that there is a lot of micro-optimization to do — I myself haven’t yet done much.

I’d love to hear experiences of feedback about this article! Next I’m planning to write about the bureaucracy of running a limited company.

Osakeyhtiön perustamisesta

Pystytin hiljattain yhden miehen osakeyhtiön, ja ajattelin lyhykäisyydessään käsitellä muutamaa sudenkuoppaa, joiden pohjalla itse käväisin. Tämä ei ole ns. how-to-postaus, koska erinomainen semmoinen löytyy esimerkiksi täältä.

(Disclaimer: Tässä postauksessa käsittelen asioita vain siten, miten ne minulla itse meni. En ota mitään vastuuta mistään. 🙂 )

Vinkki 1 – Riippumatta mitä teet, suosittelen kuivaharjoittelua sähköisessä palvelussa

Mene YTJ:n sähköiseen palveluun ja kliksuttele hakemusta läpi. Tee se vaikka samantien, vaikka et edes vielä olisi varma yrityksen perustamisesta. Sinun ei tarvitse lähettää hakemusta, mutta tätä kautta saat hyvän kuvan kaikesta siitä, mitä sinun pitää miettiä perustaessasi osakeyhtiötä.

Vinkki 2 – Sähköisessä palvelussa ei voi vapaasti muuttaa yhtiöjärjestystä

Kliksuttele hakemusta läpi ja katso miltä yhtiöjärjestys näyttää. Jos se on sinulle ok, voinet luoda hakemuksen sähköisen palvelun kautta. Jos sähköisen palvelun luoma yhtiöjärjestys ei kelpaa, valitettavasti ei ole oikein muuta keinoa kuin luoda Oy perinteisellä paperisella keinolla. Tähän löytyy starttipaketti täältä.

Vinkki 3 – Tilintarkastajan todistusta osakepääoman maksamisesta ei tarvita

Edellä linkkaamassani ohjeessa mainitaan, että osakepääoman maksamisesta pitäisi olla tilintarkastajan todistus. Ainakaan minun osaltani näin ei ollut, vaan PRH:lle riitti kuitti pääoman maksamisesta kännykän ruudulla (virkailija pyysi lähettämään sen sähköpostitse itselleen). Näin lienee ainakin, kun perustamisilmoituksessa on mainittu että yhtiölle ei valita tilintarkastajaa.

Vinkki 4 – Älä laita tilikautta yhtiöjärjestykseen

PRH:n mukaan nykyään ei enää tarvitse. Ja jos tilikauttaan haluaa muuttaa, on yhtiöjärjestyksen muuttaminen kalliimpaa kuin pelkän tilikauden muuttaminen.

Vinkki 5 – Jos haluat y-tunnuksen heti, se maksaa 7 euroa

No big deal. Mutta tästäkin otetaan nykyään rahaa.

Vinkki 6 – Vaikka olisit yhden miehen Oy, hallituksen varajäsen vaaditaan

Sisko? Vaimo? Isä? Äiti? Tämä on ihan oikea vastuu, joten lienee kohteliasta kysyä hallituksen varajäseneltä etukäteen suostumustaan.

Vinkki 7 – Tee itsesi kanssa työsopimus

Tuntuu hassulta, koska työllistät itsesi, mutta tämä on ilmeisesti hyvä olla jos kohdalle sattuu verottajan tarkastus. Haluat, että sinulla on peruste maksaa itsellesi palkkaa.

Vinkki 8 – Soita rohkeasti verottajalle

Palvelevat ystävällisesti ja asiantuntevasti. Arvostukseni Suomen virkamieskuntaa kohtaan on noussut yrityksen perustamisen yhteydessä.

Vinkki 9 – Harkitse prepaid-liittymän hankkimista tai jätä puhelinnumero ilmoittamatta

Harkitse erillisen prepaid-numeron ilmoittamista PRH:n tietoihin. PRH:sta tieto menee YTJ:hin, ja sieltä sitä ei saa pois ainakaan ennen kuin yritys on rekisteröity verottajalle. Puheluita tulee paljon. Osa niistä on huijausyrityksiä. Toinen vaihtoehto on jättää puhelinnumero antamatta, se ei ole pakollista.

What agile mindset means to me

Imagine a perfect project in an utopistic world. For you, personally,  would it be more like:

A: We can can prepare for everything beforehand. For project success we create the perfect plan and then execute the plan.

..or perhaps more like:

B: We don’t need to know anything beforehand. Our system can adapt to any changes and surprises that comes along the way. For project success we set the goal and then just start doing.

It goes without saying that these are extreme examples.  We cannot know everything beforehand, and we cannot ever build a system that can adapt to everything.  You need both type A and type B kind of thinking in real projects. But still, are your management efforts more towards type A, or type B? Which one are you pursuing more?

In my perfect world, projects are more like type B. And this is what “being agile” means to me.

From schoolbook Scrum to Kanban without estimates

This is a story about our team’s journey from schoolbook Scrum to Kanban development flow. Everything written here has actually happened. One could say that this is our #NoEstimates approach, but I tend to shy away from that term. I like to think this is more like a story of continuous improvement that has been influenced by many discussions under the #NoEstimates hashtag. For those conversations I’m very grateful.

Background

  • This is an internal multi-year product development program. We are building a product that is installed to customer premises containing both hardware and software. The life cycle of the system will be decades.
  • Team funded for nn months. Unfortunately I don’t know how the team size and the length of the funding was decided. I haven’t seen any detailed work breakdown structures or bottom-up estimates, though.
  • Distributed development. Half of the team and the PO in another country, time difference 7 hours.

Kickoff week

We started the development with a co-located kickoff week. One of the days was “process day”. Managers left the room with message “you decide how you want to work”. This is what we decided after the initial confusion:

  • Scrum was chosen as process framework
  • Decided to go with one team approach instead of having two co-located teams
  • Two Scrum Masters, one in each location
  • Common daily using video conferencing
  • Two week sprints
  • One hour weekly grooming session
  • Retrospective after each sprint
  • Planning split into two 2h meetings due to time difference. Between plannings story sub-tasking in pairs.
  • Definition of Done defined

Sprint 0

After the kickoff week we had one week preliminary “sprint 0”. That week was used to set up version control, getting bean bag chairs, video conferencing TV etc. We also had three planning sessions. In one of those we chose a baseline story for estimation. The heuristic was “this feels like medium sized story”, and it was given 8 story points.

Early sprints

After sprint 0 we started working in the way we agreed in the kickoff week. Process improvements were discussed and decided in retrospectives. Here are some of the things we changed during the first sprints:

  • We noticed we didn’t have agreed way to add more work to sprint if we run out of work. –> We decided that we would have a mini-grooming session with minimum of 2 persons to add more work.
  • Due to time difference, other location would have to wait until afternoon to find out what other location did the previous day. –> Decided to use email dailies instead
  • Grooming sessions were painful. Decided to try sub-team groomings. Noticed that things would anyway need to be discussed with the whole team, so changed back to whole-team approach.
  • Planning 2 would only be held if needed. No need to review the sub-tasks with the whole team.

Our early estimating approach

We used planning poker to estimate our stories. Usually the estimation process went like this: lengthy discussion -> “are we ready to estimate?” -> playing poker using online tool. Here’s what happened after the poker:

  • 5-5-5-5-8-8-8-8 -> pick higher
  • 3-5-5-5-3-8-8-8 -> small discussion, pick higher or settle with average
  • 1-3-2-8-13-1-2 -> Whoa! More disucssion and then new game.

Moving away from planning poker

Soon we started to notice our stories were almost every time 3 or 5 points, sometimes 8. An idea came that “what if we just stop playing the poker and agree that it’s 5 points”. Or just count the number. That’s what we did, and amazingly enough that didn’t change anything. Instead of committing to 50 story points we just committed to 10 stories.

From Scrum to Kanban

Working with distributed team with longish time difference made the Scrum start-stop cadence quite large part of the 2 week sprint: demo on Thursday, retro on Friday, planning part 1 on Monday and part 2 on Tuesday. From 10 day sprint that’s actually 40% of the days!

What happened was that we unofficially already worked on items even though they weren’t “accepted” and “committed” to a sprint. We kind of anticipated what was coming next and already started working on it. So,  we decided to make it official and move to Kanban. Here’s what we did:

  • Dropped the phased planning meetings
  • Kept the weekly planning/grooming meeting. Main idea was that stories would be groomed to ready to dev in these meetings.
  • Kept recurring retrospectives
  • Setup the kanban board to Jira, columns were setup in the same way that we already worked in Scrum (ready to dev – in dev – in review – testing – ready to demo – done)
  • Write up kanban policies for the team and rules how tickets move in the flow

Not estimating stories anymore

First column in our kanban board is ready to dev. This means a ticket has been discussed with a team and any developer can grab the ticket and start working on it.

Our entry criteria for story to be accepted to ready to dev is that minimum two team member accepts it. Our heuristic is “can we make it simpler?”. If answer to that question is “yes”, then we try  to peel the story simpler. We also try to prefer vertical stories over horizontal tasks.

Currently, using this approach, our median cycle time is little over 6 days, and mean time 8 days. Cycle time for us is the time that starts when developer starts working on a ticket and stops when it’s ready to be demonstrated.

Changes along the way

Along the way we’ve fine-tuned the process bit by bit. Here are some of the improvements we’ve tried along the way:

  • When we switched from Scrum to  Kanban, first we tried triggering demonstrations on demand (i.e. when ready to demo column reaches certain amount of tickets).  Pretty soon we switched back to regular demo cadence, it seemed to fit stakeholders better.
  • Adding queue columns to the flow, like “waiting for testing”.
  • Adjusting our WIP limits in the flow
  • Adjusting where to test and when are branches merged to master
  • Decided not to talk about implementation details in demos

As I’m writing this I feel we’ve reached a certain plateau. We have a nice flow and even though we make small adjustments to it, we haven’t changed the way we work drastically in the past few months. In a way that worries me.

But wait, we still estimate… 

Our team’s high level goal is to get 1.0 out of the oven by the end of the year. Our PO has defined a desired set of features that he would like to have in the 1.0. We have fixed time and fixed cost, so the question has been “are we able to produce enough scope that would make a meaningful marketable 1.0?”

To answer that question, I’ve used our throughput data to produce a forecast. One problem has been — because we groom our stories just in time — we don’t really know how many dev-sized stories does the rest of the backlog contain. To address that, I have simply estimated how many tickets do each of the higher level features in backlog consist of.  I have phrased my answer like “based on our current speed, it seems likely that we will reach that scope by XX”.

I have also had an idea to gather throughput metrics for the higher level features, and then use that data to forecast. I haven’t done that (yet) though. The problem with that approach is that the sample size is really small.

Trying to tackle personal biases

This is a true story, but on the other hand it’s my true story. I’m fully aware that my brain is adjusting this story. I remember what I want to remember and I’m putting pieces together to make a more coherent story. I don’t do it consciously, it just happens in my brain. To compensate for that bias, I try to list some of the thing that haven’t gone like they do in books usually:

  • We’ve had a “8 story points” ticket that took 6 months to get done.
  • When forecasting future performance, I’ve ignored dependencies and technical impacts. I’ve just assumed future work is just a big mass of tickets waiting to be chewed.
  • Grooming sessions are sometimes very painful and confusing.
  • We don’t explicitly ask “can we make this simpler?” out loud that often anymore. But I guess we’ve grown into it; cycle times haven’t been growing.
  • We have defined WIP limits to each kanban column, but they’re more like soft limits.
  • We have quite a few horizontal technical tasks and the ideal of just implementing vertical slices is quite far away
  • Our standard deviation for ticket cycle times is quite high. I don’t know if it’s too high to make any kind of forecasts about the future performance.
  • I use kanban and Kanban interchangeably, don’t really remember what was the difference and too lazy to check it up. =P

—-

So that’s my story. What’s yours? Would you like to hear something more? I’m pretty sure I’m forgetting to mention something.