DEV Community: Ioana Frincu

I automated my invoice admin with n8n (and you can copy it)

Ioana Frincu — Mon, 19 Oct 2026 17:12:15 +0000

The monthly invoice scavenger hunt

If you run a small business, you know the ritual. Once a month, your accountant asks for last month’s invoices, and you dig through your inbox for attachments, “view your invoice” links, and receipts from every tool you pay for.

It’s not hard work, but it’s easy to miss one, and it always lands on a busy day. So I built a small n8n automation that does it for me, quietly, every time an invoice arrives.

In this post, I’ll explain the logic behind it and why it’s worth it for any small business owner. The template will be available for download soon, so you can set up the same thing for your business.

What it does

Every invoice that reaches my inbox ends up in three places, without me touching it:

The right folder. It’s saved as a PDF in Google Drive, in a folder for its year and month. Missing folders are created automatically.

A monthly spreadsheet. I add a row with the supplier, their VAT code, the date, the amount, and the currency.

Out of the way. The email gets a label, so nothing is filed twice.

At the end of the month, nothing needs to be collected. I share the month’s folder with my accountant, and the spreadsheet is already inside.

How it works

The logic is simple. Every 15 minutes, the workflow checks for new invoice emails and handles them one at a time:

Work out the month. The email's arrival date determines which year and month folder the invoice belongs in.

Get a PDF. If the invoice is attached, use it as is. If the email has only a link, the workflow saves the invoice page as a PDF, like printing it.

Read it. An AI assistant reads the invoice and picks out the five details an accountant needs.

File and log it. The PDF goes into the month folder, and a new row goes into that month’s spreadsheet.

Mark it done. Label the email so it’s never handled twice. If an email has nothing usable, skip it and note why.

Two details that make it work

Not every invoice is a PDF. Some suppliers, such as Paddle (which bills for n8n) or Stripe, only send a link to an invoice page. The workflow opens that page and saves it as a PDF, so these invoices end up in the folder like any other. It skips links that require a login instead of saving a sign-in screen.

No rules to maintain. Every supplier’s invoice looks different, and some are in various languages. Instead of setting up rules per supplier, an AI assistant (Claude or ChatGPT) reads each invoice and finds the supplier, VAT code, date, amount, and currency. If it can’t find a value, the cell stays empty, so nothing disappears without you noticing.

Why it’s worth it for a small business

You don’t need a finance team to keep your books tidy. For a small business owner, this kind of automation pays off in a few ways:

No month-end scramble. File invoices as they arrive, not in a rush on the day your accountant asks.

Fewer missed invoices. A forgotten receipt can mean VAT you can’t deduct or an expense you can’t claim. Here, every invoice email is either filed or labeled with why you skipped it.

**An accountant-ready summary. **The monthly spreadsheet already has the details accountants ask for, and you can download it as Excel in one click.

Tools you already use. It runs on Gmail, Google Drive, and Google Sheets, so you don’t need to learn a new system.

The template

This workflow is now a free n8n template available here: https://n8n.io/workflows/21206-save-extract-and-log-email-invoices-with-gmail-drive-sheets-claude-and-pdfco/

You can connect your Gmail and Google Drive, point it at your invoices folder, and let it run.

It isn’t magic. Invoices that sit behind a login still need a manual download, and it’s worth checking the first few spreadsheet rows against the PDFs. But for the steady stream of everyday invoices, it means one less thing on my plate.

And if you have a supplier whose invoices always cause trouble, tell me in the comments, and I’ll make sure the template handles it.

Publish your smart contracts without going bananas! [Part 1]

Ioana Frincu — Thu, 10 Oct 2019 09:49:56 +0000

First things first, what is a blockchain?

Some say it's a database, while others think it's a system. I believe that the correct definition is the one available on Wikipedia: A blockchain, originally block chain, is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block a timestamp, and transaction data (generally represented as a Merkle tree root hash).

If a blockchain is used as a distributed ledger, effectively means that it's managed by a peer-to-peer network, collectively adhering to a protocol for inter-node communication and a consensus for transaction validation. Blockchains are considered to be secure by design as they exemplify a distributed computing system.

In our three-year quest to offer premium blockchain development to all our clients at Udevoffice, we have tried and tested many workflows for this to happen. During this time, we ended up with a simple process to develop and launch smart contracts (both for crypto and for DApps). In this article, we are focusing on:

the Ethereum blockchain and
on developing a token using smart contracts.

The focus of this article will be the ETHEREUM BLOCKCHAIN and how to develop a token using smart contracts. Before we dive in, let's take a little detour and explain more about the inner architecture of the Ethereum blockchain.
Before diving in, we will take a little detour and explain more about the inner architecture of the Ethereum blockchain. You will need programming skills and terminal knowledge. We will develop publish and unit test a coin/token called PostCoin on the Ethereum Rinkeby testnet network. Further experimenting exercises are available at the end of the article.
Propper blockchain knowledge is not required. We will walk you through all the terminology and point to the right resources whenever in-depth knowledge is necessary.

The EVM

The Ethereum blockchain is composed of nodes that communicate with each other. Each node lays on a common piece of software that, in the case of Ethereum, is called the Ethereum Virtual Machine or simply EVM.

Each node, that stores full or partial information about each block in the chain, verifies the authenticity and traceability of transactions.

The EVM is a Turing complete machine; this means that it can compute almost anything, given the necessary amount of resources. Various implementations of the EVM can be found all over the Internet. Some examples of what we worked with here at Udevoffice include go-ethereum or simply (geth), an Ethereum client written in GO, Parity client written in Rust and EthereumJ written in Java.

These are the go-to resources for whenever you want to install a local blockchain node or you want a custom setup for a private chain. If you are interested in private blockchains with custom logic for consensus algorithm, block rewards or custom Proof of Authority chains we recommend the Parity client because of their extensive documentation.

On the other hand, for the purpose of writing smart contracts, there's no need to install or use them because the Truffle framework that we are using here will simulate a local blockchain for you with no hassle.

Addresses

Each blockchain entity is uniquely identified by an address. There are two types: contract address and user address.

Syntactically they look the same, both use a 20 byte format which is a 40 character hex encoded string prefixed with 0x (example: 0xD52216266AC1EF883F3A13CDCD7C3F21523A3f7C).

The fundamental difference between the two is that one can store code (smart contract addresses) while the other doesn't. Another difference is that the initiator of a transaction is always a user address. This is important to note because as a smart contract developer the initiator of a function(transaction) chain is always the user. Smart contracts don't do anything by themselves, they just alter the initial transaction the user sent. If you come from a web development background you can think of them as middlewares for the client requests.

Transactions

Each mined block contains transactions that vary from a simple basic transaction (sending ether to another address) to complex transactions that are governed by the business requirements coded in the smart contracts. One special category of transactions is the token transactions that are governed by a Token developed over the ethereum network. The Tokens are actually smart contracts that encapsulate business logic specific to the DApp developed.

Transactions may include subtransactions. When a user calls a contract and the contract interacts with other contracts or entities on the blockchain.

There are two types of transactions that concern us smart contract developers and the main difference between them is that one is free and one costs ether. A read transaction (the free one) simply reads state from the blockchain (this can be getters or static functions) and the other are write transactions. The read transactions are never included in the mining pool (they are not mined). The read transactions are just requests that are executed on the local node that read state from the blockchain.

Consensus

This is an algorithm that has multiple implementations and is used by all blockchains. It describes how the nodes agree on what information to permanently store on the blocks that form the blockchain.

Multiple implementations of the blockchain consensus exist:

Proof of Work (PoW) consensus.
This is the algorithm used by the Bitcoin and Main Ethereum network and is tightly related to the way miners mine blocks. Mining is the process of solving mathematical equations in order to verify and include transactions.
High computational power is required by the miners to solve the mathematical equations. Each block corresponds to a specific equation and whoever solves the problem first will get the right to generate the new block in the chain.
We will relate to this consensus algorithm in this article because it is still the most spread algorithm used on the main blockchain networks. In-depth information can also be found on Cointelegraph.

Proof of Authority (PoA) and Proof of Stake consensus algorithms.

A problem with the PoW algorithm is that the difficulty of the mathematical equation increases on each block and in respect to that the computational power required increases also. So other algorithms emerged (like PoA, PoS or Delegate PoS).
The Proof of Authority algorithm has a dedicated set of nodes called validators that validate transactions with respect to a set of rules. They usually have a dedicated type of node. The validator list is, in most blockchains, that implement PoA modified with a voting system that in most cases implemented directly on the chain. (Example Kovan test network) The Proof of Stake algorithm aims to achieve distributed consensus by using a staking system in which the participants stake a portion of their wealth (in tokens or the main network coin) and become responsible of the generation of the next block. In the case of misbehaviour, the participant loses his stake.

The Delegated Proof of Stake is a hybrid of the PoA and PoS most importantly used in the EoS network.

Miners, gas and gas price

In a blockchain, most of the hard work is done by miners. They execute and put transactions in a block. On Ethereum, most of the resources needed for computation are guaranteed by those miners. They include the transactions in a mining pool then they order them using an algorithm for prioritization and finally, they generate a new block for the blockchain. The last block is linked with the one before it (hence the "chain" in the blockchain word) to achieve traceability.

In this context, the Smart Contracts can be defined (in a very simple way) as a set of instructions for the miners on how to execute user-initiated transactions.
But wait. Here you might have spotted a problem. There seems to be a lot of work for the miners! So how can we make sure that miners will want to mine our transactions?

Some kind of reward must be introduced for the miners to incentivize their work. Also, this reward should be constant per each mined block. This means that the same amount of work needs to be done to mine, secure and generate two blocks of the same size. So we need to measure blocks, and in order to do that, we first need to think of a method to measure a transaction in a block.

In order to solve this issue, some kind of variable has to be introduced that can measure the complexity of the code we write in our smart contracts. This concept will also help us determine how many transactions can fit in a block. And, finally, this should be directly dependant on the price the user pays for his transactions to be executed. On the Ethereum blockchain, this is called the gas.

Usually, miners prioritize transactions by their gas amount and gas price. The gas price is a user set value that literally translates to how much money a user spends on 1 point of gas. Therefore, the actual cost of a transaction is the total gas that transaction consumes multiplied by the gasPrice.

Smart contract code and gas consumption correlation

For a certain piece of code to be executed we, as smart contract developers, will always have to think about the amount of gas each operation will cost. This is the reason that most of the smart contract code out there is focused primarily on safety and then on gas consumption. Also, there is no point of making a super transaction that will resolve in theory our business logic without considering the gas amount that the transaction will consume. We can generate a transaction that requires more gas than a block can fit in and in consequence that transaction will never be executed on the blockchain. Also, don't think that a situation like this is far fetched. A simple iteration on a dynamic array can cause this.

We must also bear in mind that high gas consumption literally translates to a higher price for the end-user. For more information on gas prices, a maintained repository with actual gas costs per operation can be found here on Github.

Smart contract code - privacy and security

Another cause of concern when writing smart contracts is that your code is not private! You must be aware that, with every line of code you write, an "evil" eye is reading it and may try to break it. Also, there is no point of thinking your code is private because this is a decentralized technology and making your code public is an encouraged practice.

Another practise of those that develop smart contracts is to audit other developers smart contract code this is to reduce the risk of a bug to end up in the final published code. And a bug, when considering the distributed nature of the blockchain can and will most certainly be exploited!
The reason behind this is that smart contracts CAN'T be updated. Once the address is associated with the code you can consider the smart contract published and being in a totally immutable state.

In fact, the action of publishing a smart contract is a transaction itself that is mined by miners and included in a block with a specific address.