Read this before you choose this project. Real statements are messy, and cleaning messy data is the hardest thing on this whole list. Dates come in odd formats. Descriptions are inconsistent — the same shop written three different ways. Some rows are not even transactions. This is a genuine puzzle, and I am not going to pretend otherwise. Take this project if you enjoy a puzzle, if a stubborn line of scrambled text makes you lean in rather than sigh. If what you want is a clean run at a finished thing, take one of the others. There is no shame in that. Just go in with your eyes open.
The problem
Ask anyone where their money went last month and they will guess. And they will be wrong. Not a little wrong — often badly wrong, and always in the direction that flatters them.
Your statement knows the real answer. It is sitting there, exact to the pesewa. But it is four hundred rows long, and nobody reads four hundred rows. You scroll, your eyes glaze, you close it. So the statement holds the truth and you never actually look at it.
Export your own mobile money or bank statement and let Python read all four hundred rows for you. Python does not get bored on row two hundred. It will add up every transport trip, every plate of food, every airtime top-up, and — this is the one that stings — every fee. Then it tells you the truth you have been avoiding.
This is exactly the kind of job a computer is good at and you are not.
What your program does
- You export your statement as a spreadsheet — your MoMo history or your bank download.
- Your program reads every transaction: the date, the description, the amount.
- It sorts each one into a category — transport, food, fees, airtime, transfers — using rules you write.
- It totals each category, finds the biggest, draws a chart, and writes a short report.
Four steps. You already know how to do parts of the middle two — reading a file, looping over rows, checking text, adding numbers up. The reading and the drawing are the parts you will have to go and learn.
What you'll be holding at the end
A one-page report and a chart of your month, broken down by where the money actually went.
Most people are genuinely surprised by their own chart. It is one thing to know, vaguely, that you eat out a lot. It is another to see the slice for food sitting there in colour, bigger than you thought. And the fees. Almost everyone underestimates the fees. Little charges, ten pesewas here, a cedi there, four hundred times a month — they add up to a number that will make you sit back in your chair.
What you'll have to find out
These are the questions you take to the docs, to an AI, or to me. Nobody has taught you the answers yet.
- How do you read a spreadsheet into Python? You know how to open a plain text file. A spreadsheet is a different kind of file, and there is a tool that reads it cleanly, columns and all.
- How do you group rows by category and total each group? You have a pile of transactions and you want one number per category. What is the neat way to collect them?
- How do you draw a chart and save it as a picture? Not print it to the screen — save it as an image file you can put in a report or send to someone.
- How do you decide which category a row belongs to, when the description is just a jumble of text? Here is a hint at the shape of the answer: deciding whether a word appears in a piece of text is something you already know how to do. Think about
in. If"trotro"isinthe description, it is probably transport.
Remember the recipe: say the problem in plain words, find the box, install it, find the smallest example that works, run it, check it, then use it in your own function.
Requirements
To pass, your project must:
- Read a real exported statement from a file, not a handful of transactions typed into the middle of your program.
- Use at least one function you wrote, with parameters and a return value. A
categorise(description)function — take a description, hand back a category — is the obvious one. - Total the spending by category.
- Produce a report file and a chart image your program made itself.
- Come with a README that says what it does, how to run it, one thing it can't do, and one thing you would add next.
- Be something you can explain out loud, line by line. If a line is in your program and you cannot say what it does, either find out or take it out.
A word on privacy, plainly. This is your own money we are talking about. Real amounts, real dates, maybe real names. If you put this project on GitHub — and you should, it is good work — do not publish your statement. Put a small fake statement in the repo instead, a dozen made-up rows in the same shape, and say in your README that the real one is kept private. This is not paranoia. It is a normal, professional habit, and the people who read your code will notice you have it.
Done, and going further
Done is your totals by category, for one month, printed out. That is a pass, and it is a real result — you took four hundred rows of noise and turned them into five honest numbers.
Going further, if you have the appetite:
- The chart — save your month as a picture you could actually show someone.
- Compare two months. Did food go up? Did you finally spend less on transport?
- Find out what you spent on fees alone. Just that one number. It is worth the trip.
- Flag your five biggest transactions so the report opens with them.
Where people get stuck
Python reads your dates as text, not as dates. They look like dates to you, but to Python "12/03/2026" is just a string of characters. The moment you want to sort by date or pull out one month, that bites. There is a way to tell Python "this text is really a date" — you will need it.
Your amounts are text too, with a currency symbol or a comma stuck in them. "GHS 1,200" is not a number, it is a label, and sum() will refuse to add it up. You have to strip out the symbol and the comma and turn what is left into an actual number before the arithmetic will work.
Some rows are not transactions. The top of the export is often a header. The bottom is often a total, or a "balance carried forward" line. If you loop over everything blindly, those sneak into your sums and quietly ruin them. Look at the first and last few rows of your file before you trust it.
And the honest one: your categorisation rules will be wrong at first. Some descriptions will land in the wrong bucket, and some will land nowhere. That is not the project going badly — that is the project. You look at what got miscategorised, you add a rule, you run it again, and it gets a little truer each time. Improving those rules is the work. Do not expect to get it right on the first pass. Nobody does.