Capital does not begin at funding

What origination taught me about fragmentation, data, and the financial infrastructure real estate still needs.

For a while I thought the main problem of the Brazilian real estate market was access to capital.

I was partially wrong.

Capital exists.

The problem shows up a few steps earlier.

Over the last few years, working on the origination and structuring of capital for real estate operations, I got access to developers of very different sizes. Family companies. Regional developers. Groups with multiple SPEs. Projects starting out. Mature projects. Companies needing a few million and companies discussing hundreds of millions of reais.

The pattern became impossible to ignore.

Before discussing rate, collateral, term, CRI, FIDC, bridge, construction financing, or any other structure, we almost always had to do something else:

understand what was actually happening inside the company.

How much cash there was.

Where the cash was.

How much each development would still consume.

How much equity the sponsor had already put in.

How much more it would have to put in.

Which receivables existed.

Which ones were unencumbered.

Which collateral could be used.

What the cost to incur was.

What the sales velocity was.

What the maximum cash exposure was.

When, exactly, the capital would be needed.

It sounds basic.

It is not.

The larger the developer, the more curious the problem becomes.

A holding company manages several SPEs.

Each SPE has its own bank accounts, contracts, suppliers, receivables, budget, schedule, debt, and dynamics.

Part of the information is in the ERP.

Part is at the bank.

Part is in spreadsheets.

Part is in the sales system.

Part is in accounting.

Part is in someone's head.

And an uncomfortably large amount is still scattered across emails, WhatsApp, and files someone has to find before a meeting.

The result is one of the most expensive ironies in real estate:

companies capable of managing hundreds of millions of reais in sales value still have to reconstruct their own financial reality to answer fundamental questions about capital.

This is where I began to understand that our work as originators started long before origination.

Capital does not accept ambiguity

On the other side of the table there is a fund, a bank, an asset manager, a securitization company, a FIDC, a family office, or some other provider.

They may disagree on price.

They may disagree on structure.

They may hold completely different mandates.

But they all need the same thing before putting money into a transaction:

clarity.

A capital provider needs to understand the asset, the sponsor, the cash flow, the collateral, the receivables, the corporate structure, and the capacity to execute.

The worse the information, the greater the uncertainty.

The greater the uncertainty, the higher the premium demanded to take the risk tends to be — or simply the higher the chance the transaction never moves forward.

In 2024, during a discussion hosted by the Brazilian Chamber of the Construction Industry on funding for small and mid-sized developers, participants went as far as pointing out that a large share of those companies struggles to access financing precisely because of deficiencies in governance and transparency.

That matters because there is an enormous difference between:

needing capital

and

being prepared to receive capital.

The industry talks a great deal about new sources of funding.

It talks about capital markets.

It talks about bank disintermediation.

It talks about private credit.

It talks about securitization.

But it says little about the infrastructure a developer needs in order to present its operation in a continuous, organized, and intelligible way to whoever supplies that capital.

That is the problem that started to bother us.

The fragmentation is bigger than it looks

I recently heard Thomas von Buettner, founder of Paggo, describe a problem I recognized immediately.

He was talking about the fragmentation of a developer's financial life.

The bank on one side.

The ERP on another.

Spreadsheets in the middle.

Different systems.

Different people producing reports about the same company and, sometimes, arriving at different numbers.

Paggo has a correct reading of that problem and built its thesis around consolidating the financial operation. Its own material describes developers operating across ERPs, spreadsheets, specialized systems, and banking portals that do not talk to each other. The consequence, according to the company, shows up in three places: operating cost, financial loss, and worse decision quality.

I would add a fourth.

Cost of capital.

Because fragmentation does not end at the finance department.

It runs across the company and reaches whoever has to analyze it in order to put money into it.

If the numbers have to be reconstructed every time a funding process begins, there is a structural problem.

If the data room is born after the need for money has appeared, there is a structural problem.

If nobody can say with confidence how much capital an SPE will consume over the next twelve months without opening five spreadsheets, there is a structural problem.

And if a developer only starts discussing funding when it realizes cash is about to run out, the conversation probably started too late.

This is where Seferu's thesis changed.

We built the first version for ourselves

Seferu was born very close to capital.

Diagnosis.

Structuring.

Origination.

Our job was to understand an operation, find a viable structure, and connect it to the right providers.

Except that created an internal need.

To structure an operation well, we had to organize the client well.

We had to consolidate financial information.

Organize documents.

Understand their entities.

Separate SPEs.

See accounts.

Transactions.

Flows.

Receivables.

Obligations.

Capital.

We had to turn a fragmented company into something that could be understood.

And to do that, we started developing our own infrastructure.

At first, the software was a tool to improve our work as originators.

That distinction matters.

We did not start by looking at the market and saying:

“Let's build a SaaS for developers.”

We started by trying to solve a problem we ourselves were facing.

We wanted to arrive at a transaction and quickly know what was going on.

We wanted documents to be organized.

We wanted to see the accounts in one place.

We wanted to understand the entities.

We wanted to know the financial history.

We wanted to cut the time spent looking for information so we could increase the time spent making decisions.

The more we developed that machine, the more one thing became evident.

It was not useful only to us.

It was useful to the client.

In fact, it was perhaps more useful to them than to us.

From financial organization to capital intelligence

What began as internal infrastructure is becoming Seferu's main product.

We are building a financial platform for real estate companies capable of organizing the financial life of holdings, SPEs, and developments in a single environment.

But centralization is only the beginning.

I do not want to build yet another place where a CFO looks at balance, revenue, and expense.

Good tools for that already exist.

The question that interests us is a different one:

what does this data say about the company's capital?

How much capital will each development still consume?

When will that capital be needed?

How much equity is deployed?

Where is it deployed?

How much of it can come back to the sponsor?

Which receivables can be used?

Which assets have debt capacity?

How much of the next need can be financed externally?

Which structure lets the developer keep growing while making better use of its own capital?

Those are capital allocation questions.

That is where Seferu starts to become something other than a financial tool.

We want to build what we have internally started calling a Capital Operating System for Real Estate.

A layer between the developer's operation and the capital markets.

The ERP will keep knowing what happens on the construction site.

The sales systems will keep knowing what happens in sales.

The banks will keep moving money.

Financial tools will keep executing important tasks.

Seferu wants to answer a different question:

what should the developer do with its capital right now?

How much. When. How.

There are three questions we want to make trivial.

How much capital will be needed?

When will it be needed?

How should it be structured?

Imagine a developer with eight SPEs.

Today it may know how much cash it holds.

It may know how much it has sold.

It may know the construction budget.

But we want it to be able to open Seferu and see:

R$ 43 million of capital need over the next twelve months.

R$ 12 million in November.

R$ 18 million in February.

R$ 13 million in May.

And, more importantly:

R$ 31 million of that need potentially financeable externally.

We do not want the developer to discover it needs R$ 20 million in the same month it needs the R$ 20 million.

We want it to know months in advance.

And we want the structure to be partially designed by the time the moment arrives.

Receivables.

Bridge.

Construction financing.

Structured credit.

Equity.

Or a combination of them.

The intelligence begins inside the software.

The execution can stay with us.

Software in front. Capital behind.

That also changes the role of our capital operation.

Seferu will keep structuring and originating transactions.

Except that no longer has to be the entry product.

Our capital office can work almost silently.

The software will be in front.

The developer will not have to come to us saying:

“I need R$ 30 million.”

Perhaps the platform itself will notice, months earlier, that a given SPE is going to need R$ 30 million.

When that moment comes, we will not merely be receiving a credit request.

We will have context.

History.

Accounts.

Financial movement.

Documents.

Receivables.

Projections.

Corporate structure.

The behavior of the SPEs.

That changes the conversation with the capital markets.

On one side, the developer comes to understand its own need better.

On the other, the provider receives a more organized transaction.

In the middle, Seferu gets to work with far more clarity.

That is the point where software and capital stop being two separate businesses.

They become parts of the same system.

Opening the machine

Until now, much of this infrastructure was conceived as a machine to organize our own origination clients.

We are changing that.

The platform will also be opened to developers who hold no origination mandate with us.

This point is fundamental.

You do not need to raise money with Seferu to use Seferu.

We want the platform to have value even during periods when the company does not need capital.

It has to help the entrepreneur manage their portfolio better.

To see their SPEs.

Understand their cash.

Organize documents.

Track receivables.

Consolidate information.

Project needs.

Measure the use of equity.

And make better decisions.

If a capital need appears in the future, we will be there.

If it does not, the product still has to justify its existence.

That independence is what turns a commercial tool into infrastructure.

The market does not need another spreadsheet

For years the sector solved fragmentation by adding tools.

One system for one thing.

A spreadsheet for another.

Another system to fix what the previous one did not do.

Then someone has to consolidate all of them.

That cycle does not scale.

The answer to fragmentation cannot be more fragmentation.

We believe the next step for real estate's financial infrastructure will be consolidating operational and financial data into a layer capable of producing capital intelligence.

Not merely recording the past.

Anticipating the future.

Because there is a fundamental difference between accounting and capital.

Accounting asks what happened.

Capital has to ask:

what happens next?

The origin of our category

There is a sentence I have been repeating internally:

capital begins long before funding.

It begins in the quality of the information.

In the organization.

In the governance.

In the ability to see the financial future of each development.

In the ability to show that clearly to whoever can finance your growth.

The more time I spend working between developers and capital providers, the more convinced I become that this market's next great infrastructure will sit exactly at that intersection.

Between data and capital.

Between the SPE and the fund.

Between the operation and the funding.

Between what happened and what needs to happen.

That is how we got here.

We did not decide to build software and then go looking for a problem.

Origination showed us the problem.

Fragmentation forced us to build the software.

And now we realize that what we built to organize our clients can be useful to an entire industry.

Seferu is ceasing to be merely a company that helps developers find capital.

We are building the infrastructure for developers to understand, organize, plan, and access capital better.

That will be our main mission from here on.

How much. When. How to finance.

That is the problem we want to solve.

Leo Bentier