DEV Community: Meiglyph

Automating Team Expense Reports with Python

Meiglyph — Tue, 08 Sep 2026 11:16:40 +0000

In many small teams, each employee submits their monthly expenses as a separate Excel file. Someone — usually whoever handles approvals — then has to open every single file and manually copy the rows into one master sheet before anything can be reviewed.

It's slow, and it doesn't scale past a handful of people.

I built expense-tool, a small Python CLI that automates this: point it at a folder of expense files, and it produces one clean, aggregated summary.

Why this problem

The usual alternatives don't quite fit for a lot of teams:

Excel macros work, but require someone comfortable writing VBA to set up and maintain.
Power Query is powerful, but the setup isn't intuitive if you're not already familiar with Excel's data tools.
No-code automation platforms (Zapier, Make) are great for connecting services, but are often overkill — and an extra subscription — for what is fundamentally a "read some files, sum some numbers" task.

Meanwhile, the actual manual process (open each file, copy rows, paste into a master sheet) is exactly the kind of repetitive task that's easy to automate with a short script, once the shape of the problem is well-defined.

What it does

expense-tool runs as a single CLI command and does three things in order:

Combine — reads every Excel file in a folder and merges them into one table.
Aggregate — sums expense amounts by employee and category.
Format — writes the result to a new Excel file with a bold header row, and highlights any row above a configurable amount threshold.

python expense_tool.py sample_data

Summary written to expense_summary.xlsx

Employee	Category	Amount
john	Meals	68.00
john	Office Supplies	15.30
john	Travel	42.50
sarah	Meals	145.00
sarah	Software	29.99
sarah	Travel	320.00

Rows above the threshold (sarah's Meals and Travel entries here) are highlighted in the output file, so whoever reviews the summary can spot larger expenses at a glance.

Design decisions

A few choices shaped how the tool is put together — and why.

One file, three functions

At this scale — three features — splitting the project across multiple files would have added structure without adding much clarity. Instead, expense_tool.py has one function per feature:

load_expense_files — reads and merges the input files
aggregate_expenses — groups and sums
write_formatted_excel — writes the styled output

A single Typer command (run) calls the three in order: load → aggregate → write. If the tool grows — more input formats, more output options — splitting into modules becomes worth the added structure. For now, one file stays easy to read top to bottom.

Employee name comes from the filename, not a column

Since each file represents one employee's report, adding an "Employee" column inside every file would just be repeating the same value on every row. Instead, load_expense_files derives the employee name from each file's name (john.xlsx → "john") and adds it as a column only after merging:

for file_path in folder_path.glob("*.xlsx"):
    df = pd.read_excel(file_path)
    employee_name = file_path.stem
    df["Employee"] = employee_name
    dataframes.append(df)

This keeps each individual file simple — no extra column employees have to fill in correctly — while still giving the merged table everything it needs for aggregation.

pandas for data, openpyxl for style

write_formatted_excel uses pd.ExcelWriter with engine="openpyxl", so pandas handles writing the data and openpyxl handles the formatting on the same file afterward:

with pd.ExcelWriter(output_path, engine="openpyxl") as writer:
    df.to_excel(writer, index=False, sheet_name="Summary")
    worksheet = writer.sheets["Summary"]
    # openpyxl styling happens here, on the same worksheet

This keeps the data-processing logic (grouping, summing) written the simple pandas way, and treats formatting as a separate, later step — rather than mixing styling logic into the aggregation code.

Highlighting is a plain loop over rows

For highlighting rows above the threshold, there's no need for anything more elaborate than checking each row's Amount and applying a PatternFill when it exceeds the limit:

for row_index, amount in enumerate(df["Amount"], start=2):
    if amount > highlight_threshold:
        for col_index in range(1, len(df.columns) + 1):
            worksheet.cell(row=row_index, column=col_index).fill = highlight_fill

highlight_threshold is a parameter with a default value, so it's easy to adjust for a team with a different sense of what counts as a "large" expense.

Trying it yourself

git clone https://github.com/meiglyph/expense-tool.git
cd expense-tool
pip install pandas openpyxl typer
python expense_tool.py <input_folder>

Each input file just needs the columns: Date, Category, Description, Amount, Payee, Notes. Full details are in the README.

What's next

The current version assumes every input file shares the same columns — a reasonable assumption inside a single team with a shared template, but not something to take for granted more broadly. A natural next step would be adding an optional department-level breakdown, or making the highlight threshold configurable from the command line instead of the function signature.

For now, the core loop — combine, aggregate, format — does exactly what it needs to.

I Built BuildNext: A Tiny Tracker That Won't Let My Side Projects Stall

Meiglyph — Wed, 19 Aug 2026 08:58:26 +0000

I have a problem a lot of indie devs have: too many side projects, and no idea
what to actually do next on any of them. Every project had a mental backlog
a mile long, which meant every project felt overwhelming — so I'd avoid all of them.

So I built BuildNext: a small Flask app with one rule baked into the data model
itself — every project gets exactly one next action. Not a todo list. One thing.

What it does

Add projects and move them through five stages: Idea → Planning → Building → Testing → Published (or Paused)
Each project has exactly one "next action" — with an optional due date that flags when it's due today or overdue
"Mark as done" logs the completed action to that project's history, so I can see momentum over time
Optional blocker note + GitHub link per project

Stack

Flask + Flask-SQLAlchemy + SQLite, server-rendered Jinja templates, no JS
framework. Deliberately boring — this is a tool, not a demo of a framework.

What's next

Right now it's a personal tool I run locally. No accounts, no cloud — just a
GitHub repo I can point people to. If enough people want to actually use it
rather than just read the code, a real deploy is the obvious next step.

Repo: https://github.com/meiglyph/build-next

Why I Kept My CLI Tool's Tags as Plain Text

Meiglyph — Sun, 09 Aug 2026 05:59:43 +0000

Keeping Tags as Plain Text — Adding Features to brain-cli Without Losing the Point

Why I Built This

brain-cli started as a tiny CLI with exactly four commands: add, list, show, search. Under the hood, it just appends lines to Markdown files. No database, no index — a thin wrapper around plain text.

After using it for a while, one thing started to bug me. The more notes piled up, the harder it got to find the one I wanted. search only does substring matching, so there was no way to say "just show me the work-related notes" or "just the study log." So I added tagging.

What I Built

First, tagging on add:

brain add "Built my first CLI command." --tag learning --tag cli

--tag (short form -t) can be repeated, and internally each tag just gets turned into a #tag string appended to the line:

- Built my first CLI command. #learning #cli

Next, filtering search by tag:

brain search SSH --tag work

It's a simple AND condition — only lines that match both the query and the tag get shown.

Finally, a tags command to see everything you've been using:

brain tags

   Tags
┏━━━━━━━━━┓
┃ Tag     ┃
┡━━━━━━━━━┩
│ #python │
│ #study  │
└─────────┘

It scans every note, collects words starting with #, dedupes them, and prints them alphabetically. That's the whole implementation.

Why Tags Stay Plain Text

This is the part I actually spent time thinking about. When implementing tags, there were two real options:

Store tags as structured data (YAML frontmatter, JSON metadata, etc.)
Keep tags as literal #tag strings inside the line

I went with option 2, without much hesitation. The core value of brain-cli, as I see it, is that the storage is transparent plain text. You can open ~/.brain-cli/notes/*.md in any editor, with or without the CLI, and it just works. You can hand-write #tag directly in your editor and it behaves exactly the same as if you'd used --tag.

If I'd made tags structured metadata, brain-cli would have become a tool that "breaks" the moment you bypass the CLI. That would contradict the simplicity the tool was built around in the first place. When adding a feature, keeping the existing design intact mattered more than making the feature technically "cleaner."

What I Deliberately Didn't Build

A couple of other commands came up as candidates alongside tagging. I considered both and skipped them — here's why.

brain rm (delete a note)

I decided this wasn't worth building. Since storage is just Markdown files, you can already delete one with rm ~/.brain-cli/notes/2026-08-09.md. A dedicated command would mostly add complexity — confirmation prompts, safety checks — for very little actual benefit.

brain edit (open a note in $EDITOR)

This is the one feature I still think might be worth adding later. Fixing a typo or adding a follow-up thought isn't something you can do by just re-running add — that's a real, recurring friction point. Since it would just delegate to $EDITOR, the implementation itself would stay simple. If there's a "next feature," this is probably it.

The general rule I used: bias toward not adding things, but let real, recurring friction override that bias.

How I Actually Built It

Each feature went through the same cycle: implement, write tests, update the README, commit. Instead of building everything at once, I finished one feature completely before starting the next. By the end, there were 10 passing tests and two commits pushed to main.

Takeaway

The part that actually took time wasn't writing the code — it was deciding how much to structure, and what not to build. The more a tool grows, the harder it gets to keep it simple. This time, I think that trade-off worked out.

Hello, DEV Community!

Meiglyph — Tue, 04 Aug 2026 02:49:19 +0000

Hi, I’m Meiglyph.

I have a background in design, and I’m currently learning Python and exploring software development.

As I build small tools and web applications, I often discover useful lessons about programming, debugging, user experience, and the development process itself.

On DEV, I plan to share:

・What I learn while studying Python
・Lessons and mistakes from my projects
・Practical tips I discover during development
・Thoughts on combining design and programming

I’m still learning, so this blog will also be a record of my progress.

I hope my experiences can be useful to other beginners and people who are building their own projects.

Thanks for reading. I’m looking forward to learning and sharing with the DEV community!