How Your AI Agents Can Now Find, Check, and Send Invoices Directly on Comarch E-Invoicing

Agent adoption in large organizations went from 27% to 40% in a year. Agents are arriving in finance functions faster than the systems around them were built to expect, and an agent is worth only as much as it can reach. Comarch E-Invoicing answers this need. A customer’s own AI agent works on the platform directly, with nothing built in between.

Invoice Status and Where It Lives

An invoice is the most interesting document in a finance function to put an agent on, and the hardest one to reach. Two organizations have to agree on it, and a tax administration has to accept it, so its status, its history, and its outcome all sit outside the company that issued it. What an agent is worth here depends on how far beyond its own house it can see.

That reach is the part of the agent story that only a platform can deliver. However good a customer’s agents are, they cannot open somebody else’s platform from the outside. Comarch built that side of it.

The platform describes its own operations in a form that an agent reads at the moment it needs them, so a customer’s assistant works out for itself which one answers the question it was asked. The agent then pulls exactly the invoices in question and nothing else. No copy of a customer’s document history has to be loaded into a model, exported to a spreadsheet, or kept in sync anywhere, because the agent reads what it needs at the moment it asks: their model, their assistant, their vendor. Nothing on the platform assumes which agent is asking, so a customer who standardizes on one assistant this year and a different one next year changes nothing on our side.

What a Customer’s Agent Can Do

Comarch E-Invoicing sends, receives, validates, converts, and archives invoices in the format each destination requires, including government platforms, across a business network of more than 100,000 entities. AI Agent Access opens a defined set of those platform operations to the customer’s own agent, which:

• finds a document, without anybody opening the interface to look for it
• reads its state, including the technical, business, and legal statuses behind it
• retrieves the file the document was built from
• runs the invoice sending flow, end-to-end

All four are live on the platform today.

Connecting an assistant to a system like this one is normally a development project. An API is a specification written for a person: somebody reads it, decides which call answers the business question, writes the client, maps the platform’s vocabulary into their own code, and maintains that translation every time either side changes. Here, the platform ships each operation with its own description, saying what it does, what it needs, and what it will not do. The agent reads that at the moment somebody asks it a question, and works out the rest for itself.

So the translation step that used to be a development task now happens by itself, on every request, and a change on either side sends nobody back to their code. The questions do not have to be anticipated either: whoever builds a client has to guess in advance what the business will ask, while an agent handles the question nobody thought of, as long as the operations cover it.

Who Uses It and Across Which Markets

The people this reaches are the ones who already have an account and rarely open it. The clerk chasing a single rejection, the shared service center answering a supplier, the controller checking a batch cleared before the books close. They ask in their own words and get the answer with the document behind it.

What comes back carries more than one country. A finance team sending invoices into several markets asks one question and gets one answer, because the platform has already done the per-destination work. The statuses the agent reads are the statuses each destination gave back, so neither the agent nor the person asking has to know which mandate applied.

What Your Team Does Not Build

Five things a customer’s team does not build, each worth pricing on its own:

• The client build. Nobody has to read an interface specification, work out which calls answer the business question, build the client, and test it.
• The semantic mapping. Platform statuses, document states, and partner identifiers do not have to be translated into the customer’s own vocabulary in code because the descriptions travel with the operations.
• The second build. An organization that changes assistant vendor, or runs two, does not repeat the work. The platform side is unchanged.
• Interface training for occasional users. The people who touch invoices twice a month never learn the screens. They ask in their own language, in the tool they already have open.
• Ad hoc report requests. An agent that can query documents and statuses formats its own answer, so the request that used to arrive as a ticket does not arrive.

 A Worked Example, on Your Own Numbers

Take one question your team answers by hand: where is this invoice, and why has it not cleared. Today, somebody opens the platform, finds the document, reads the technical, business, and legal statuses, interprets them, and replies. Time it once. If that is four minutes, including the context switch, and your service center does 200 of them a month, one question type costs a little over 13 hours a month. The agent answers it in one exchange. The two numbers that decide whether this is worth anything to you are the four minutes and the 200, and both of them are yours, not ours.

Deployment Without a Project

On the Comarch side, switching this on for a customer takes a setting rather than a release, so there is no queue to join and no version to wait for. The same setting turns it off again.

On the customer’s side, the work is issuing credentials and pointing their assistant at the platform. 

Nothing here needs a budget line. One team can switch it on, see what it answers over a few weeks, and decide from that whether to widen it.

Control and audit

Your audit position does not change. Legal validation, format conversion, and clearance still run on fixed rules on the platform. No model decides whether an invoice is compliant, and no agent can make it decide. There is nothing new to explain to an auditor or a tax administration, and in a regulated flow, that is a stronger answer than automating the decision.

Nothing new to authorize. An agent sees and does exactly what the same account could see and do through the platform’s API and nothing else, with partner filtering applied the same way. Your security team still runs its review, and it is a narrower one: no second authorization model to assess, no new route into the platform, and no new place where the data comes to rest.

No second copy of your data. An agent reads the existing records. Nothing is copied for it to work against, and no new place where invoice data lives is created, so the answer to where your invoices sit is the answer you already have.

The decision is reversible. Access stays off until you ask for it, goes on for the teams you choose, and can be switched off the same day without waiting for a release window. There is no rollout program to approve and nothing to unwind if the answer turns out to be no.

What It Does Not Do

• It opens a defined set of operations rather than the whole platform. They were chosen around the sending flow, because that is where a customer’s agent has something useful to do first.
• It cannot start a process of its own. An agent asks and sends within what it has been given, and does not set the platform running on something nobody asked for.
• It does not touch legal validation, format conversion, or clearance, by design, as above.

Where This Goes Next

The depth stays where it has to be. The country rules, the validation, and the clearance logic that make an invoice legal in each market all sit on the platform and all run on fixed rules, and none of that moves because an agent is asking. What has changed is how far that work now reaches: past the ERP, out to whichever agent a customer runs.

Reach is what makes the redesign possible, and the redesign is where the money is. A finance team that keeps its current process and puts an assistant on top of it gets a faster version of the same process. The return comes from rebuilding the process around agents, and that rebuild needs a platform that answers them. 

Within a few years, we expect most invoice inquiries never to reach a person at the customer, nobody in accounts payable to open a supplier platform to find out where a document is, and the agent mesh a customer builds internally to expect every platform it touches to answer it directly. That is where this market is heading, and the platform answers agents now rather than once the demand is easy to measure. Comarch leads its clients through the AI era by shipping the part of it that clients cannot ship for themselves.

The work continues. More of the platform will answer agents directly, because that is where this market is heading, and the platform is being built for it.

AI Agent Access is available today for any customer who asks for it.

Mateusz Czarnecki

Head of Product Management for Comarch EDI / E-Invoicing