Unbuilt · taking signups
Match received Pix to your invoices, and stop reading names
Import the bank export, or connect the account. It matches on value, timing, payer document and the fragments of description that do exist, and hands you a short list of the ones it could not resolve.
- Works with a static key, where no order identifier exists
- Learns that this payer name means that client, once you say so
- Flags duplicates and partial payments rather than guessing
- Exports what your accountant asked for, in the format they asked for
Expected launch price R$39 a month, flat, any volume.
Why this is hard at all
Pix was designed so that a payment can carry structured identification. A dynamic QR code binds an order to a payment through a transaction identifier, and every transaction in the scheme carries a unique end-to-end reference assigned at the moment it is sent.
Almost none of that reaches a small business, because a small business gives out a static key. Someone types the key into their banking app, sends the amount, and possibly writes something in the description field. What lands in the statement is a name, a value, a timestamp and a partially masked document number.
So reconciliation becomes a matching problem on weak signals — and the weakest of them is the payer name. A partner pays for the company. A parent pays for a course. An employee pays and expects reimbursement. The name that arrives is a real person's name and it is nowhere in your client list.
What actually arrives, by how you were paid
The same R$450 payment, received four ways. The right-hand column is the whole product hypothesis.
| How it was received | Identifier present | Payer document | Free-text description | Reconcilable automatically |
|---|---|---|---|---|
| Static key, typed manually | No | Partially masked | Whatever they typed, often blank | Rarely |
| Static QR code on an invoice PDF | No | Partially masked | Sometimes prefilled | Sometimes |
| Dynamic QR with a transaction id | Yes | Present | Set by you | Almost always |
| Payment account link (Asaas, Cora) | Yes, inside that account | Present | Set by you | Yes, within that account only |
| Pix Automático (recurring) | Yes | Present | Set at authorisation | Yes |
Source: Fields as they appear in bank statements and OFX exports, checked August 2026 against several Brazilian banks. Masking behaviour varies by institution.
The first two rows are how most one-person businesses get paid, and they are the two rows without an identifier. Everything below the line is a solved problem sold by somebody else.
The five ways reconciliation actually fails
None of them are about the payment failing. Every one is about the payment arriving and meaning nothing.
- The payer's name is not the client's nameA spouse, a partner, an accountant, a company director paying personally. This single mismatch is the largest category, and it is the one no amount of care on your side prevents.
- Round numbers collideFour clients on the same R$500 monthly fee, three of whom pay in the same week. Value matching alone cannot separate them and confidently pairs the wrong two.
- Someone pays two invoices in one transferNow the value matches nothing at all. It is arithmetic rather than lookup, and it is the case a spreadsheet handles worst.
- A partial payment arrives with no explanationR$300 against a R$450 invoice. Is it a deposit, a dispute, or a typo? The statement will never tell you and the client will not volunteer it.
- The description field contains something almost useful"pagamento", "nf", "ref outubro", a truncated order number. Enough that ignoring it wastes information, not enough to match on reliably.
What it would cost
Flat, in reais. It has to be small, because the person with this problem most acutely is billing a few thousand a month.
Expected launch price
R$39per month
Founder priceR$25 per month
Flat, per business, any volume of receipts. Roughly US$7 at August 2026 rates — priced for a one-person business, which is where this problem is worst.
This product does not exist yet. The number above is the price we expect to launch at, not a commitment. If the waitlist says it is wrong, it changes.
What the price covers
- Import from OFX and CSV bank exports, and from statement formats that are neither
- Matching on value, date proximity, payer document and description fragments
- A remembered mapping from payer name to client, taught once
- Detection of combined payments, partial payments and duplicates
- A short unresolved list — the point of the product is that this list is short
- Export in the layout your accountant already uses
What it does not cover
- Being an ERP. No stock, no orders, no invoicing, no payroll. If you need those, Conta Azul or Bling is the correct purchase and this is not.
- Issuing invoices or fiscal documents. Adjacent, heavily regulated, and a different product.
- Tax advice of any kind, including whether a given receipt requires a fiscal document.
- Initiating payments. It reads; it never moves money.
Founder price holds while the account stays open.
Objections
- Just use dynamic QR codes and the problem disappears.
- Correct, and it is the honest first recommendation on every page here. The reason it does not close the question is that you do not control how you are paid: the client already has your key saved, the recurring transfer already exists, and the person paying you at the end of a job types the key rather than scanning anything. Dynamic codes fix new arrangements and not the installed base.
- My payment account already reconciles this.
- It reconciles what it processed. If a client pays a key held at a different bank — which happens whenever someone uses a key you gave out two years ago — that transaction is invisible to it. The gap is not a deficiency in those products; it is the boundary of what they can see.
- R$39 is a lot for a one-person business.
- It is, and this is the objection I take most seriously — for someone billing six thousand a month it is a genuine decision rather than a rounding error. If the waitlist comes back almost entirely at the notify tier, the honest reading is that the problem is annoying but not subscription-annoying, and it should be a one-off tool instead.
Tell me when this exists
Useful in the context field: roughly how many Pix you receive a month, and whether you use a static key.