Bre-B for Your Business: Getting Paid Is Easy. Knowing Who Paid Is the Hard Part

With Bre-B, getting paid in Colombia is now almost instant: the customer sends money to a key or scans a QR code and the funds arrive in seconds. For a business, the hard part isn't receiving the transfer. It's knowing what it was for: which order, which invoice or which customer paid, without someone checking a phone by hand and matching names and amounts. Colombia's central bank, Banco de la República, has published draft rules that propose, among other things, a "Payment Reference" field designed for exactly that, but they aren't in force yet. In the meantime, what you can do today is put the whole flow in order: give every charge its own number and make sure each payment is tied to its order, its inventory and its invoice.

This guide explains, without jargon, what changed with Bre-B in its first year, what the draft proposes for businesses, why the real bottleneck is reconciliation, and which questions to ask about your website and your operation before the final rules arrive.

Why is Bre-B no longer a novelty?

A year ago, Bre-B was "the new way to send money." Today it's a habit. According to the first-year review published by Banco de la República (October 6, 2026; in Spanish):

• More than 36 million users have at least one registered key.
• The system has more than 116 million registered keys, of which 45 million have been used to receive at least one payment.
• In its first twelve months there were more than 1.7 billion transactions worth more than 262 trillion Colombian pesos.
• 62% of transactions are under 50,000 pesos, which the bank itself reads as a sign of everyday use between people and small merchants.
• 245 institutions are connected, compared with about 25 that took part in instant-payment schemes before Bre-B.

In the words of Leonardo Villar, the bank's governor, in that same review: in just one year Bre-B went from being a new way to pay to becoming part of daily life for millions of Colombians.

For a business, the practical takeaway is simple: your customers already know how to pay this way, and they're probably already offering to. The question is no longer "should I accept Bre-B?" but "what happens in my operation every time one comes in?"

What is Banco de la República proposing for businesses?

On October 2, 2026, Banco de la República published Draft Regulation PR-DSP-008 for public comment, which changes the rules for Bre-B. It's worth being clear from the start: this is a draft, not a regulation in force. According to the summary by CERLATAM (in Spanish), comments were accepted until October 17; after reviewing them, the bank will have to define the final version. At the time of writing, that final version hasn't been published.

Of the changes in the draft, four speak directly to businesses:

1. Payments to legal entities. The draft explicitly adds a payment category for when the recipient is a company. As Minuto60 explains (in Spanish), this points Bre-B more clearly toward commercial transactions, although the draft doesn't say that every such use will work automatically from day one.
2. A "Payment Reference" field. A numeric or alphanumeric code attached to the transfer, meant to identify the product or service being paid for. Ana María Prieto, director of the bank's Payment Systems Department, told Minuto60 it will work like paying a utility bill: a specific number that makes each transaction easier to trace. The technical guidelines and the rollout schedule would be defined later.
3. Value-added services. The draft defines services or features that complement instant-payment processing. In practice, it opens the door for institutions and providers to build tools on top of Bre-B.
4. Static and dynamic QR codes. Participants will have to be able to generate, read and use both. A static QR can stay on the counter while the customer types in the amount; a dynamic QR is generated for a specific transaction and can carry information about that payment.

If we had to sum it up in one sentence: the draft aims for payments that, besides arriving fast, arrive with information that tells you what they're for. That's exactly what most transfer-based payments are missing today.

What's the real problem: receiving the payment or reconciling it?

Reconciling means confirming that every peso that came in matches a specific sale, and that the sale was recorded where it needs to be. It sounds like a month-end accounting task, but in a business that gets paid by transfer, it happens every day, several times a day.

Here's an illustrative example that doesn't describe any specific business. A shop that sells through WhatsApp and its website receives three transfers for the same amount one morning. One comes from a name that doesn't appear on any order, because a relative paid. Another has the right name, but that customer has two open orders. The third arrives unannounced, because the customer paid before confirming. Someone on the team has to open the phone, look at the receipts sent over chat, match them against the order spreadsheet, ask, wait for an answer and, finally, ship. Meanwhile, inventory hasn't been updated and the invoice hasn't been issued.

None of that is a Bre-B problem. It's a structure problem: the payment arrives with no link to the order, and whoever reconciles ends up acting as the cable between the bank, the chat, the spreadsheet and the invoicing system. It's the same situation as tools that don't talk to each other, only now there's money involved.

The market is already working on this. In mid-October, La República (in Spanish) reported on Sumia, a company building tools so organizations can receive Bre-B payments, identify transactions and reconcile their income without relying on manual processes, with real-time notifications. We're not mentioning it as a recommendation: it's a sign that the conversation has moved from "how do I get paid?" to "how do I know what I was paid for?"

Which questions should you ask your website and your operation today?

Before thinking about tools, it's worth sitting down with your team and answering these questions honestly. You don't need to know technology to answer them; you need to know how work actually happens today.

• Does every order have its own number? Not just on the website: also the ones that come in through WhatsApp, by phone or at the store. Without that number, there's nothing to tie the payment to.
• Does that number travel with the charge? When you ask a customer to pay, do you give them the amount and the key, or also something that identifies their order?
• Where can you see today's payments? If the answer is "on someone's phone," that phone is currently the business's reconciliation system.
• Who confirms that a payment belongs to an order, and how is it recorded? If it depends on a single person, the business stops when that person is out.
• Does a confirmed payment update inventory? Or is stock adjusted later, "when someone remembers," with the risk of selling what you no longer have?
• Does the payment trigger the invoice, or does the invoice wait for the payment? This question has a tax answer worth knowing (more on that in the next section).
• What happens with exceptions? Partial payments, overpayments, payments from a third party, refunds. Every business has its own, and they should be written down.

If you sell online, there are two more questions. First: when a customer pays at checkout, is the order confirmed automatically, or does someone check it? Many payment gateways notify the store when a payment is approved; if your website doesn't listen for that notification, your team ends up confirming by hand what the system already knew. Second: does your checkout offer the payment methods your customers want to use? Whether it accepts Bre-B, PSE, Nequi or cards depends on your gateway and how it's integrated; what matters is that, whatever the method, the payment stays tied to the order.

What about the invoice? It's issued when you sell, not when you get paid

Many businesses wait for the transfer before invoicing. It seems logical, but Colombia's tax authority, the DIAN, has clarified that's not how it works. According to DIAN Concept 015975 of 2026, as explained by Plantillas Contables COL (in Spanish), the obligation to invoice arises when the sale is made or the service is delivered, and doesn't depend on whether the customer has paid. There's also no general authorization to issue an invoice late for a transaction that wasn't invoiced on time.

Why does this matter in an article about Bre-B? Because if the invoice depends on someone confirming the payment by hand, any delay in reconciliation becomes a delay in invoicing too. Separating the two moments helps: the sale generates the invoice, and the payment is reconciled against that sale (and that invoice) when it arrives. For that, once again, you need a number that connects both. Check the details of your case with your accountant; here we only care about the flow.

What can you do today without waiting for the final rules?

The Payment Reference, if approved, will make reconciliation much easier. But the businesses that benefit most will be the ones that have already organized what happens before and after the payment. Here are five steps you can take now, with or without new tools:

1. Give every order a unique number, across every channel. Website, WhatsApp, phone and in-store. That number is your "reference" for now, even if the bank doesn't carry it yet.
2. Make that number travel with the charge. In the payment message, in the payment link, in the receipt the customer sends back and on the invoice. If a piece of data shows up everywhere, it can be matched without guessing.
3. Bring payments into one place. A single record where you can see the day's payments and their status (pending, reconciled, exception), instead of screenshots spread across several chats and phones.
4. Decide who reconciles, how often, and what happens with what doesn't match. Write down the most common exceptions and how to resolve them. It's the least glamorous step and the one that saves the most time.
5. Connect what can already be connected. If you sell online, have an approved payment confirm the order, update inventory and notify the team without manual steps. If you charge in-store, keep the counter QR separate from per-order charges so they don't get mixed up.

Not all of this needs to be automated at once. Some steps are solved with order and a written rule; others do require connecting your website with your gateway, inventory and invoicing. If you want a way to decide which is which, we explain it in When to Automate (and When Not To). And if you're thinking of leaving it for later, it's worth reading The Hidden Cost of "We'll Fix It Later": a messy payment flow usually gets more expensive as volume grows.

Where should you start? Structure first

Bre-B solved the hard part for the customer: paying is fast and easy to understand. The next part is up to the business. When a payment arrives with no link to its order, every transfer is a small manual task; when it arrives tied to a number that's also on the order, the inventory and the invoice, it stops being a task and becomes a data point.

The final rules may take time, and their technical details will shape what can be automated. But the groundwork doesn't depend on them: one number per order, one place for payments, a clear owner and the connections that already exist. That's what we at DevelopWave look at first when we design a business's website, checkout or internal tools: how money flows from the moment the customer says "done" until the sale is recorded.

If you'd like to look at what that flow looks like in your business, tell us how you get paid today and we'll think it through with you.