Pix Reconciliation

The two arrangements

Same scheme, same settlement, entirely different records afterwards.

DimensionStatic key or static QRDynamic QR or billing
What it isA permanent address you hand out onceA request for one specific payment
AmountWhatever the payer typesFixed by you, or explicitly open
Carries your referenceNoYes
ExpiresNeverYes, and can carry a due date
Effort per paymentNone — it already existsOne request has to be generated
Works for a recurring clientThey pay from memory, foreverNeeds generating each cycle, or an authorised recurring arrangement
ReconciliationManual, on weak signalsAutomatic

Every row favours dynamic except the fifth, and the fifth is the one that decides what actually happens. Effort per payment is why the installed base is static.

Why the worse option wins

A static key requires nothing. You give it out once and money arrives forever, from clients who saved it, from a recurring transfer somebody set up in 2024, from a WhatsApp message you sent last year and cannot now unsend.

A dynamic code requires an action every time. Somebody has to generate it, attach it to the right invoice, and send it before the client pays — which is the sequence that breaks, because the client frequently pays before being asked.

The result is that businesses adopt dynamic codes for new arrangements and continue receiving static payments indefinitely from everything that predates the decision. Six months after "we've switched to dynamic QR", roughly half the receipts are still arriving on the old key. That mix is the actual operating condition and it is what any honest tool has to be built for.

Moving as much as possible to dynamic, realistically

Four steps. The point is not purity — it is shrinking the manual pile.

  1. 1

    Split by client, not by intention

    List your recurring clients. For each, decide whether you can practically change how they pay, and be honest about the ones you cannot.

    The client who has paid the same key on the first of the month for two years is not going to start scanning a code, and pretending otherwise wastes the effort you could spend on the ones who would.

  2. 2

    Change the new ones first

    Every client onboarded from today gets a dynamic code and never learns the static key. This costs nothing and compounds.

    Six months of this converts the majority of new volume without a single awkward conversation, which is the cheapest progress available.

  3. 3

    For the immovable ones, use a distinct key

    A second key, used only by a defined group, makes the ambiguity smaller — you know which bucket a payment came from before you look at anything else.

    This is a workaround rather than a solution and it is genuinely useful. Narrowing the candidate set is most of what matching is.

  4. 4

    Accept a permanent residue and plan for it

    There will always be payments that arrive unannounced with no reference. The realistic target is that this is a short weekly list rather than a monthly afternoon.

    A tool that promises to eliminate the residue entirely is describing something the scheme does not make possible. The honest promise is a smaller pile.

Done properly this takes a quarter and removes most of the problem. It does not remove all of it, which is why the product on this site exists at all — if step four had a clean answer, there would be nothing left to build.

When a static key is genuinely the right choice

Five situations. Reconciliation is not the only consideration.

  • You are paid at the counter, in personA printed static code on the counter is faster than generating one per sale, and speed at the point of payment matters more than tidy records.
  • Payments are rare and largeFour payments a month need no automation. Reconciliation at that volume is a two-minute glance and any tooling is overhead.
  • The client pays a fixed amount on a fixed datePredictable value and predictable timing are strong matching signals on their own. This is the case where a static key is very nearly self-reconciling.
  • Donations or open-value paymentsThere is nothing to reconcile against, because there was no invoice. A permanent address is exactly the right instrument.
  • Your systems cannot generate codes at allPerfectly common. Adopting a whole platform to obtain dynamic codes is a large change to solve a matching problem, and frequently the wrong trade.

Rows two and three cover a large share of very small businesses, which is worth stating on a page selling a reconciliation tool. Below about twenty receipts a month, do nothing.

Questions

Can I have more than one key?
Yes — a document number, a phone, an email and a number of random keys, subject to per-institution limits. Using distinct keys for distinct purposes is an underused way to make reconciliation easier at no cost.
Does a dynamic code cost anything to generate?
It depends entirely on the institution or provider. Some include it, some charge per transaction. Worth checking before designing a workflow around it, because a per-transaction fee changes the arithmetic on small payments.
Can I stop a static key from being used?
You can remove or replace a key, and payments to a removed key fail. That is a blunt instrument — it will break the recurring arrangements you had forgotten about, which is either the point or a disaster depending on how carefully you listed them first.
Is a static QR code any better than a typed key?
Marginally. The payer scans rather than types, which removes typing errors and sometimes prefills a description. It does not add a transaction reference, so the reconciliation problem is the same one.

For the residue that will not move

In the context field: roughly what share of your receipts still arrive on a static key.

How much do you actually want this?

Your email lands in one private Slack channel that only Bruno reads. It is not added to a mailing list, sold, or passed to a third party.