If simply tracking a few dozen transactions per year, you don't need a database. Just write to text files, "a pile of files".
Tab-delimited or CSV (comma separated values) are both commonly used.
Writing CSV/tab-delimited files is not difficult. But you may want to look for a library to assist anyways, such as Apache Commons CSV for Java.
Learn about file locking and concurrency issues. Consider writing a fresh file after which you delete or move/hide the old.
SQLite is indeed another good choice. The creator's intent for SQLite is to be one step up from using text files. It is not meant to be a serious database contender, and so it has limited features such as few data types. SQLite and its file format are designed for portability, even across different kinds of CPU processors.
☞ Your case sounds like a good fit.
SQLite is an excellent product, hugely useful for countless apps on many platforms. But keep in mind the "lite" part.
To quote D. Richard Hipp, the creator of SQLite, from his keynote address (video) at PGcon 2014:
“SQLite is not a replacement for PostgreSQL.
SQLite is a replacement for fopen().”
For serious heavy-duty work, such as enforced data types, huge number of rows, complicated joins, fancy SQL, large amounts of memory, and so on, consider using a database other than SQLite.
Here is a very subjective comparison chart of some various databases. Quite arbitrary and approximate, not drawn to any scale. Based on my own experience. Meant only to give some basic orientation to newbies (not to start any flame wars).
The point here is that SQLite gives you much more power and saves you much programming with a relatively small bump in hassle over plain files. But for serious database work, consider the products other than SQLite.