At Xerocon London 2026, Regan Ashworth, Head of Ecosystem Governance at Xero, built a working, Xero-connected e-commerce app live on stage in 15 minutes. No code, one ready-made prompt, and a real invoice sitting in a real Xero organisation at the end to prove it.

The build was deliberately simple: a one-product online store (a beltless trench coat, for the Seinfeld fans) that creates a contact and an invoice in Xero after every sale, then opens the online invoice for the customer to pay. A complete e-commerce flow, working end to end, in less time than a coffee run.

The whole build happens on screen, and you can follow every step

The demo runs on Lovable, an all-in-one development platform that acts as your software developer in a browser tab: you describe what you want in plain language, and it builds it. The shortcut that makes 15 minutes possible is a skill from Xero’s prompt library, which teaches Lovable how to build a proper integration with the Xero API (the way apps pull information out of Xero and put it back in) so you never have to touch the difficult parts yourself.

Along the way, Regan covers the things every new builder needs to know: why you should always search the Xero App Store before building anything, how to create an app at developer.xero.com and get your client ID and client secret (explained with a great hotel key analogy), and why a well-built app only asks for the data it actually needs.

This is how to build a Xero integration without coding, and you don’t need a software development background to follow along. Pause, rewind, and build alongside the video, then head to developer.xero.com/ai for the AI toolkit, the prompt library, and the skills from the demo.

Watch all our AI/vibe coding demos on the Xero Developer YouTube channel.

Watch a working Xero-integrated app get built in 15 minutes (live at Xerocon London 2026) was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, many customers who work with unsupported banks, fintechs, payment platforms, or custom financial systems still rely on manual statement uploads to get data into Xero. We’re changing that by expanding the Xero Bank Feeds API so vetted partners can send non-bank statement data into Xero using the existing feeds flow. This capability is still currently in beta.

That means fewer CSV workarounds, less repetitive admin, and a more automated path into Xero bank reconciliation for customers whose data sources don’t fit the traditional financial institution model.

Why we’re making this change

The gap is straightforward: if a customer’s data source isn’t supported by an existing bank feed, the fallback today is usually manual import. That process is slower, more error-prone, and not a great fit for businesses that want a more automated workflow.

We also know developers have been asking for a better way to help customers bridge that gap. The aim here is to make it easier for approved partners to automate statement delivery into Xero, while still preserving the distinctions that matter between direct bank feeds and other imported data sources.

What’s changing

Rather than introducing a completely separate ingestion API, we’re reusing the existing Xero Bank Feeds API infrastructure and the same core endpoints developers already know: POST /FeedConnections and POST /Statements.

This new lane is designed for vetted partners who need to push statement data from non-bank sources into Xero bank accounts. It will not be surfaced as a connection option in Xero bank search or the standard Xero UI feed discovery flow; that experience remains for direct bank feeds, with setup handled through the partner app instead.

In product, customers will be able to distinguish this data from certified bank-provided feeds, with the source shown as App in the Xero UI.

Under the hood, that data is also classified separately from trusted financial institution feeds so Xero can continue to treat partner-imported statement data differently from direct bank feeds where needed.

What this means for developers

For developers, the shape of the integration stays familiar, but the use case expands.

You’ll still need to register a Xero app, have the Bank Feeds scope enabled for that app, implement OAuth, create feed connections, and send statement data through the Statements endpoint.

You’ll also need to design the experience around the parts that matter most to customers: choosing the right account to connect, picking a safe feed start date, handling reconnects and cancellations cleanly, and making sync state easy to understand in your app.

And because reconciliation quality matters, this flow is intended for final or posted transactions rather than pending activity, with enough transaction detail to support reconciliation directly in Xero.

Important guardrails

This is not a new open transaction import API for every developer from day one. Access will begin with a small set of vetted partners and a lightweight certification process, with scope to expand over time.

The initial model is also intentionally one-way. In this phase, the API supports creating new statement lines in Xero, but not updating or deleting them through the API.

It also won’t be used to overwrite or append data into accounts that already have an active trusted bank feed from a financial institution.

For the beta, broader two-way sync workflows, feed discovery in bank search, and App Store listing support are out of scope.

What this means for customers

For customers, the outcome is simple: less manual importing and a better path to reconciliation when their financial data doesn’t come from a supported bank feed.

A strong implementation should help customers see statement data in Xero without relying on repeated CSV uploads, reduce missed or duplicated imports, and reconcile using the same core Xero bank reconciliation experience they already know.

It should also make setup and ongoing sync clearer, so customers can understand what’s connected, what has synced, and what action is needed next without having to guess.

What’s next

We’re starting small, with pilot partners first, and we’ll expand from there as we validate the experience, monitor behaviour across downstream systems, and learn from partner feedback.

The direction is clear: more supported ways to get high-quality statement data into Xero, without sending customers back to manual file uploads every time their data source falls outside the traditional bank feed model.

Expanding the Xero Bank Feeds API for non-bank statement data was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Xero App & Agent Hackathon lands in London on 4 and 5 July: two days, £9,000 in prizes, and one mission, to build AI-powered apps and agents that do not just look good in a demo but actually work in the real world. Once the building stops, the pitching starts. With that much on the line, you will have three minutes in front of the judges to turn everything you made into a story they believe in. That is not much time, so we asked Annie Terry, our Head of Platform Marketing at Xero, how to make every second count.

Across the hackathons she has organised over the years, Annie has watched a lot of pitches, including a memorable one from a passionate team that turned their idea into a fully functional app and business that is now used by thousands of small businesses. They remain a valued member of our ecosystem today. Her view is simple: the build gets you to the room, but the pitch is what wins it. Here are her top tips for making the pitch count.

1. Treat your three minutes like the scarce resource it is

“Every second is a premium asset,” Annie says. In 180 seconds you need to capture the judges’ imagination, explain how you built the thing, and prove there is a real market for it. That sounds like a lot, and it is, which is exactly why a rambling pitch loses.

The fix is to decide in advance what each chunk of time is for, and then protect it. If you try to say everything, the judges will remember nothing. Pick the few points that matter most and give them room to land.

2. Name a specific problem before you show your solution

The strongest pitches start with a person, not a product. Be precise about who your customer is and the friction they hit every single day while running their business. Deep understanding will help you get really specific on the problem and more importantly makes your solution feel inevitable.

“Fall in love with the problem and build deep customer empathy. You’ll then be able to showcase your app as the natural solution to the problem,” Annie says. Once the pain is clear, the question to answer is equally clear: how exactly does this person’s day get better after they use what you built? Spell out the value to the customer in plain terms, and point to the size of the opportunity while you are at it.

3. Let the demo do the talking

This is the part Annie is most insistent about. The demo is the moment your project stops looking like a weekend hack and starts looking like a real app, so it deserves the biggest share of your time.

Show, do not tell. Walk the judges through the main thing a customer would actually do with your app, and lead with your most impressive feature. Skip the sign-up screens and the settings pages, since nobody was ever won over by a registration form. And if doing it live feels risky, with dodgy wifi or a fragile build, record a clean walk-through in advance. A demo that works beats a live demo that might not, every time.

4. Show your technical chops without drowning the room in detail

Judges want to see that you know what you are doing under the hood, so give them a quick, confident tour of how you built it. Name the core technologies and the platform you developed on, and keep it brief.

Then get specific about Xero, because this is a Xero hackathon and the judges want to see how you built on the platform. Which Xero data did you connect to, and which parts of our API gave you an edge while you were building? This is where our webhooks are worth a look. Rather than your app constantly asking Xero “anything new yet?” over and over, webhooks let Xero tell your app the moment something changes. It means less repetitive checking, more responding to real events, and a better experience for everyone. One customer cut that repetitive checking by 40%. We shipped a new credit note webhook in March and we are now turning our attention to payments, so there is plenty to build with.

Finally, call out anything genuinely clever you did. If you found a neat optimisation or solved a hard problem in an unexpected way, the judges want to hear it.

5. Follow a pitch flow that already works

You do not have to invent a pitch structure. Annie’s recommended flow maps neatly to your three minutes:

• 0 to 30 seconds, the hook. Define the customer problem and the opportunity.
• 30 to 100 seconds, the demo. Show your solution in action.
• 100 to 150 seconds, the tech. Share your stack and how you used the Xero API.
• 150 to 180 seconds, the future. Wrap up with the features you would add over time.

Practise it with a timer. The most common way to lose your ending is to run long and get cut off before you reach it.

6. Make your slides work on a projector, not just your laptop

Your slides are scenery, not the script. Keep them big, bold, and simple so they support you rather than compete with you.

Use massive fonts, think 30 point and up for body text and 60 point and up for headings. Go high contrast, with light text on a dark background or the reverse, so everything stays readable across the room. Stick to one major idea per slide, because the moment people start reading your slides, they have stopped listening to you. And lean on icons, screenshots, and simple charts instead of dense paragraphs.

7. Bring the energy, and own the room

“Energy is contagious,” Annie says, “and judges invest in people as much as ideas.” You built something real, so do not let nerves undersell it. Stand tall, speak with authority, and let your enthusiasm show.

A few traps to sidestep: do not bury the judges in jargon, because confusion is not the same as being impressed. Always have a working demo of what you built. And watch the clock so your closing line actually gets heard.

8. Win the questions after the buzzer

The pitch is not quite over when the timer stops. Think ahead about the gaps in your three minutes, the things you did not have time to cover, and be ready for the judges to probe them. Anticipating the obvious questions and having a calm answer ready is often what separates the top projects.

See you in London

The work happens at the desk, but the win happens at the microphone. Build something you are proud of, then give it a pitch that does it justice. We cannot wait to see what you make.

Got a question for the team before the hackathon? Come and ask us in the Xero Developer Day and Hackathon Discord server, your home for everything Dev Day and the hackathon.

Land your hackathon pitch: a playbook for winning the room was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every month, the Xero Developer ecosystem welcomes new certified apps to the Xero App Store.

Each app added to the Xero App Store gives Xero users new solutions to work smarter and take their business further.

We welcome the following apps to the Xero App Store this month:

XO Report

XO Report pulls live Xero data directly into Excel using custom formulas. Build profit and loss statements, balance sheets, trial balance reports, and data tables straight in your spreadsheet — with one-click refresh across multiple organisations.
Available regions: Everywhere

Portal 360

Portal 360 is an AI-powered practice management and client portal app for accounting firms and bookkeepers. Manage clients, communication, workflows, approvals, and integrations in one place to reduce admin and improve the client experience.
Available regions: AU

Claryx

Claryx is a financial planning and analysis platform for Xero finance teams. Plan, report, analyse, and consolidate on a single source of truth, with AI agents that build three-way budgets and board pack financials from your live Xero data. SOC 2 Type II certified.
Available regions: Everywhere

FourFourFive

FourFourFive helps accounting practices identify recurring spend patterns and import purchase orders into Xero quickly and safely, reducing manual data entry and improving accuracy for recurring transactions.
Available regions: UK

Medfin

Medfin is an AI-powered business intelligence platform for dental groups and clinics. It provides up-to-date analytics and metrics across practice management systems, accounting platforms like Xero, and CRM tools — giving healthcare businesses a clearer view of performance.
Available regions: UK

Remittance Go

Remittance Go solves the manual data entry bottleneck for Xero users who receive single bank payments covering multiple invoices. It extracts data from PDF remittance advice, matches payments to the correct invoices in Xero, and bundles them into a single batch payment ready for reconciliation.
Available regions: AU

Field Ascend

Field Ascend is an intuitive field service platform for scheduling jobs, managing engineers, quotes, invoices, assets, and customer communication in one place. It connects with Xero to help service businesses reduce admin and stay organised as they grow.
Available regions: Everywhere

Grow your app with Xero

Want to grow your business and join the Xero developer ecosystem? Learn more about what it means to be a Xero developer or app, and how we help support your success here.

Xero App Store: meet June’s apps was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s the short version of our June developer webinar: the key points from each section, with the full detail saved for the recording. We picked up last quarter’s question — is everyone a developer now? — talked through the latest technical updates and migration prep, and looked ahead to the Dev Days and Xerocons coming up.

If you couldn’t make it, you can watch the full recording on the Xero Developer YouTube channel.

Meet the panel

• Corey Leung: Developer Marketing Manager (Host)
• Breana McHugh: Senior API Technical Specialist
• Mae Nacario: Lead Product Manager
• Kirsten Spilg: Ecosystem Commercial & Special Projects Lead
• Millie Soutter: Senior Developer Marketing Manager
• Annie Terry: Head of Platform Marketing
• Regan Ashworth: Head of Ecosystem Governance

The fireside chat: the Rise of the Builders in the Ecosystem

Annie Terry and Regan Ashworth joined us to talk about what vibe coding means for builders. New app registrations are up fourfold since January, and a wider mix of people — small businesses, accountants, and bookkeepers — is now building. More builders is good for everyone, but trust, security, and the professional engineer’s role still matter. When a project outgrows a non-technical builder, our development partners are there to take it further.

Technical deep dive

Mae ran through the key API updates:

• XPM 3.1 is here — JSON responses, UUIDs, field selection, and pagination. v3.0 retires 30 April 2027; Leads, Purchase Orders, and Suppliers go earlier, on 5 August 2026.
• Role-based permission changes land 29 June — Reporting permission for journals, and BankAccountAdmin to edit bank details. No code changes needed.
• A new “Connect App” permission rolls out — existing Standard and Advisor users inherit it automatically.
• Granular scopes — your app already has them; move across before 13 September 2027.
• New in the AI toolkit — a Xero-hosted remote MCP server, in closed beta with a soft launch expected in Q2. Explore the full Xero AI Toolkit.

Migration: a quick refresher

Apps created before 2 March are moving to usage billing by early July. Before you migrate: review your feature use, complete your certification or security assessment, and make sure your billing details are up to date (or you’ll be capped and moved to Starter). App Store listings need the Plus tier or above, and Starter is now capped at 1,000 calls per tenant per day.

Developer programs

Six ways to grow with Xero: optimise your listing, stay connected, get reviews, run your own campaigns, join the Growth Program, and the Referral Program. Plus, the Global App Awards close 10 July (winners announced 18 August), the Xero Developer Advisory Council is open for applications, and we’ve relaunched our Development Partners program with cleaner listings, better discovery, and a tiered model to come.

Events: London, Denver, and roadshows

• 🇬🇧 London — Xerocon 8–9 July at Olympia, plus a hackathon (4–5 July), an Ecosystem Payment Partners meetup (6 July), DevDay (7 July), and a 20th-anniversary-themed after-party. (London Xerocon exhibitor packages are now closed.)
• 🇺🇸 Denver — DevDay 18 August, Xerocon 19–20 August (exhibitor packages still open), and the after-party on 20 August.
• 🌏 Roadshows — New Zealand (October–November) and Asia (Malaysia and Singapore in October), with Australia and the UK to follow in 2027.

Where to find us

Catch us in person at our events, online at our quarterly webinars and weekly office hours, and across @XeroAPI on X and Instagram and Xero API on LinkedIn. Join the conversation on the Xero Developer Day Discord Server, explore developer.xero.com, share feedback on UserVoice, or reach us at api@xero.com.

See you at the next update!

Webinar recap: June 2026 developer update was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the third episode of Is everyone a developer now?, we changed the rules. Our first two builds ran on Lovable, an all-in-one platform that handles hosting, databases, and deployment so you never have to think about them. This time, Regan and I wanted to see what happens when you trade that comfort for control. So we opened a terminal, moved to Claude Code, and brought in Henry, an engineer on Xero’s infrastructure team who specialises in the systems that automatically build, test, and ship software, to guide me through a tool that’s a real step up

But the platform switch isn’t the headline. This is: the whole app worked from a single prompt. On every build we’ve done so far, we’ve spent roughly as much time debugging as building. This time, Fable 5 took one well-prepared prompt and produced a working, Xero-connected app on the first go. For a series where things usually break before they work, that’s a genuine leap. Fable 5 has since been pulled, so this turned out to be the last thing we built with it.

The brief: a tracker that checks the books, not just the boxes

This build didn’t start with one of our ideas. It started with an App Partner who told us exactly what they wanted: a tracker for month-end close. For accountants and bookkeepers, closing the month is a checklist (reconcile the bank, post the journals, review the reports, confirm everything ties out) repeated across every client before they can move on. The request was simple. Give me one place to see where each client is in that process.

We could have built a static checklist in ten minutes. Instead we asked a better question: what if the tracker connected to Xero and read the books behind each item? You still tick things off, but now the tick box is backed by live data, not just someone’s memory that they did it. That’s the difference between a plain to-do list and something genuinely useful.

Why we traded Lovable’s convenience for Claude Code’s control

Lovable makes the hard decisions for you, and that’s its strength. You describe what you want, press publish, and the things a working app needs behind the scenes (hosting, source control, and the database) are all taken care of. Claude Code is the opposite trade. It can do everything a developer would do, which means you get fine-grained control over every stage, and you also have to make the decisions Lovable quietly makes on your behalf.

Worth saying up front: there’s more than one way into Claude Code. You can use it through a desktop app or the browser, much like any chat window, or through the terminal. We went with the terminal because it’s what Henry and Regan are comfortable with, but that’s a preference, not a requirement.

And for someone non-technical, the terminal is easily the most intimidating door to walk through. As Henry put it, it’s just a text version of your computer: the same things happening behind a graphical interface, with the pictures stripped away. That reframe helped. It’s less foreign once you realise nothing magic is going on; it’s the same machine, talking back in plain text.

The flow: most of the real work happened before the prompt

We didn’t open the terminal and start typing code. That single-prompt result wasn’t luck. It was the payoff for everything we did before hitting enter. The more effort you put into shaping the right prompt up front, the less time (and the fewer tokens) you burn fixing things later. A few minutes of planning saved us what would normally be an afternoon of debugging. Here’s how that groundwork broke down:

We scoped the idea in chat first. Before writing a single prompt, we used Claude to pressure-test what was even possible, mapping each checklist item to what the Xero API can actually return: profit and loss, the balance sheet, aged receivables and payables, GST and BAS, and manual journals. Knowing this upfront meant we built around what’s real, not what we wished existed.

We handed it the right scopes. Xero moved to new granular OAuth 2.0 scopes in June 2026. The scopes page is client-side rendered, so Claude couldn’t read it directly. But rather than guessing, it searched our developer docs and found the correct granular scopes anyway. No leftover broad scopes, which is exactly what you want from a brand-new app.

We planned before we built. In the terminal, we switched to Fable 5, which had launched only that morning (and has since been pulled), turned on plan mode, and let Claude lay out its approach before touching any code. The plan was thorough. It suggested a progress bar, status lights, and per-item notes we hadn’t even asked for. We reviewed it like product managers: describe the problem, sanity-check the approach, change anything wrong now rather than after it’s built.

We let it run. The build took about 15 minutes and was, almost unbelievably, a single prompt. The one thing that went wrong wasn’t the code. We’d connected to a Xero organisation with no data, because the demo company expires if you don’t use it. Once we spun up a fresh demo company, the tracker lit up: 12 unpaid invoices to chase before close, the balance sheet, the lot. Essentially a one-shot wonder.

The tech stack: three parts, not thirty

The point of vibe coding is that the stack is increasingly modular. For this build it really came down to three things:

• Claude Chat: where we shaped the idea before building, pressure-testing what the Xero API could do, refining the prompt, and looking up the right scopes.
• Claude Code, running Fable 5: where everything got built. We used its plan mode to think before writing, approved the approach, then let it make the rest of the calls, including choosing Node for the web app and writing every line of code.
• The Xero API: the engine. The interface and logic are generated, but the value comes from 20 years of accounting data structure underneath. Connecting to it meant the new granular OAuth 2.0 scopes for read-only access to the books, and keeping our credentials in a local file rather than pasting them into the model.

The honest part: working isn’t the same as shippable

Here’s where Claude Code earns its keep, and where it asks more of you. Right now, our tracker is exactly as secure as my laptop. Only I can reach it, which is fine for a prototype and a terrible idea to expose from a work machine. To make it usable by other people, you’re into real decisions: where to host it, where the code lives for source control, where to store data, and whether that data has to sit in a particular country. Lovable answers all of those for you with a publish button. With Claude Code, as Regan put it, we’re probably not even halfway.

That’s not a knock on either tool. It’s the trade. If you want a proof of concept in front of people fast, an all-in-one platform is brilliant. If you want control over every decision, Claude Code gives it to you, along with everything you now have to decide.

Henry’s advice for anyone feeling the overwhelm was the most useful thing in the episode: the volume of unfamiliar stuff doesn’t mean you’re not cut out for this. It’s just how development works. Learn one thing at a time. Ask an AI chat like Claude or Gemini to describe what’s happening rather than blindly accepting it. Do that consistently, and the learning compounds faster than you’d ever expect.

What’s next: from “runs on my machine” to published

We got a connected, working app in a single prompt, and we’re only partway to something other people could actually use. That gap is the interesting bit. In a future episode we want to keep going: source control, hosting, a database, security, and making it discoverable. The move from “runs on my machine” to “published and trusted” is its own build, and we’d like to show you exactly what it takes.

Fable 5 is gone for now, but that matters less than you’d think. As Henry pointed out, it isn’t far off Opus, and the way you build this way is fundamentally the same whichever model you use. The parts that last are the Xero API underneath and your own judgement about what’s worth building. Swap the model, keep the approach, and the next one will clear the bar Fable 5 set.

Watch the full episode on the Xero Developer YouTube channel to see the build in action.

Fable 5 built us a working Xero-integrated app from a single prompt, before it got pulled was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our last article, Jon Bell, Xero Developer’s Principal Product Designer, argued that the traditional labels of “designer” and “developer” are blurring, replaced by a new kind of creator he calls the “builder.” If the roles of design and engineering are blurring, what about the person who sits between them? The product manager.

We sat down with Ketan Kittur, Xero’s VP Product — Core Accounting, to find out.

Few people have had a front-row seat to as many platform shifts as Ketan has. He started his product career in the early days of mobile internet, helping build the infrastructure that powered data services on mobile phones at Openwave Systems, before moving to Nokia where he led the browser and developer platform as smartphones reshaped the industry. He then spent nearly eight years leading the developer platform at another major accounting software company, where he oversaw 10x growth in active developers and third-party app integrations, before taking on the platform and AI partnerships portfolio at Box. Now at Xero, he’s responsible for the core accounting platform and US products.

That kind of career, spanning mobile, SaaS, platform ecosystems, and now AI, means Ketan has seen this pattern before and knows what actually changes and what doesn’t. So we asked him: is the vibe coding shift actually different from what came before? And what does it mean for the Xero ecosystem?

Three prototypes, three real problems

When we asked Ketan how he’s been using AI tools, he didn’t give us a philosophical answer. He gave us a list.

Over the past several months, Ketan has built working prototypes using the Xero MCP server and Claude. These are internal proofs of concept, not finished products or blueprints for external developers to replicate. Their purpose is to test what’s possible, gather real customer feedback, and inform what gets built properly down the line. Each one was targeted at a real business problem.

The first was a livestock accounting tool for Australian agriculture, a capability Xero doesn’t currently offer. Ketan built a Claude chat interface that could handle the complexity of writing and posting to journals. “Livestock accounting is a capability we just don’t have,” he explains. The prototype let him explore what that could look like for customers before any engineering was involved.

The second was a prepayment and approval workflow tool, built and submitted as a hackathon entry. The problem it addressed is a familiar one for small business owners: they often can’t identify which invoices are prepayments, and end up manually creating repeating journals. The prototype automated that process end-to-end.

The third was the most ambitious: a proof of concept built for Xero’s enterprise pre-sales team. Xero currently supports only two tracking categories, which creates friction for larger businesses that need more. Ketan used the MCP and Claude layer to create additional tracking categories and write the output to a spreadsheet, with a clear path to a Postgres database if it went to production. The goal was to support pre-sales conversations, showing large enterprise prospects what a more flexible Xero could look like.

The thinking behind all three was the same: push the current limitations of the platform far enough that you can show a customer what’s possible, take that feedback, and then build a product that actually makes sense.

The thing engineering backlogs used to kill

Ketan has navigated major technology shifts throughout his career, and when we asked him whether this one is genuinely different, his answer was clear. It’s not just speed. It’s the nature of what’s possible.

“Previously, you had to get on an engineering backlog and test it,” he says. “It just took a long time. It curtailed creativity. It limited potential opportunities.”

The ability to prototype a concept quickly, put it in front of a real customer before writing a product specification, and gather real feedback changes the shape of the entire discovery process. Ketan describes it as “inspiring”: for internal teams, who can suddenly see what’s possible, and for customers, who can react to something tangible.

This doesn’t mean product managers are replacing engineers. Ketan is emphatic on that point. Once you’ve tested a concept, he says, you still need engineering for infrastructure, scalability, and production. That’s not going away. What’s changed is that the earlier stages of the process, forming a hypothesis, testing a concept, gathering customer feedback, can now happen without waiting.

Everyone gets a better toolkit. Not a replacement.

One of the recurring questions across this series has been what effect has AI had on traditional roles. Regan Ashworth argued that “everyone who wants to be a developer can be now.” Jon Bell suggested that “developer” and “designer” are being replaced by a single word: builder.

Ketan’s view is more measured, and it’s worth sitting with.

“I don’t want to take the position that design is going to go away or engineering is going to go away,” he says. “I think everyone now has a very powerful toolkit to hone their own craft to a level that was not possible previously.”

The distinction matters. It’s not that roles are merging so much as the tools available to each role have become far more powerful. A product manager with access to MCP and Claude can now validate an idea before it ever touches an engineering backlog. When it comes to scaling, securing, and shipping, engineering expertise remains the irreplaceable ingredient.

“We still need all these functions,” Ketan says. “They serve a purpose. They have a craft to them. What you can do now is work with each other to create and amplify an even better product than was previously possible.”

The best product managers have the best judgement

A more powerful toolkit, though, also raises a more important question, one that every article in this series has circled: what happens when someone with no engineering background builds something and tries to put it in front of real users?

Ketan doesn’t hedge here. As a product leader, he has a specific frame for it.

“I think some of the best product managers have the best judgment,” he says. “Judgment on how much to build, when to say no, how to build insights and look at signal versus noise.” In his view, that judgment is what defines great product leadership, and it’s exactly what’s being tested by the rise of vibe coding.

“Anyone who says, ‘I’ve done two or three vibe coding prototypes, I’m going to push that as a PR to production.’ That’s terrible judgment,” he says. “You don’t know what you don’t know.”

Security is the clearest example. When you’re not an expert in security protocols, Ketan argues, you can’t know what you’re missing. The answer isn’t to avoid building. It’s to be humble about what the prototype is and isn’t. “You have to work with experts in the space,” he says. “That’s how you build it the right way.”

This is the argument that separates the prototype from the product. Vibe coding has genuine power in the discovery phase: it lets you move fast, test ideas, and show customers what’s possible before a line of production code is written. But as Ketan puts it, the last 25–90% of the work, depending on the complexity of the app, still requires proper engineering. The judgment to know where that line is? That’s on the builder.

More quality apps, not just more apps

Looking at the broader ecosystem, Ketan sees a shift coming, but it’s not the one you might expect.

“Perhaps we may see more apps,” he says. “But I actually see it slightly differently. We will see more quality apps.”

He’s candid about the other side of that prediction. Alongside the quality, he expects to see a lot of what he calls “AI slop”: apps that aren’t well thought through, that work well as a prototype but don’t actually solve the underlying problem. Many of these will stall in that final stretch because their creators didn’t know what they didn’t know.

His recommendation isn’t to raise the barrier. It’s to change the framing. Rather than treating AI as the final word on development, he wants to see builders use it as a fast path to a real question. “Give developers patterns and ideas on how to test their concepts quickly,” he says. “Help them understand how to use AI in development, versus thinking about AI as the end-all for development. There’s a difference, and I think that will open up their minds.”

That’s ultimately the thread that runs through everything Ketan shared: prototyping is about asking better questions faster, not skipping the hard work. That distinction, knowing when the prototype has done its job, is what separates a good product instinct from a wasted sprint.

Ready to start building? Explore the Xero AI Toolkit, including the MCP Server, Agentic SDKs, and Prompt Library, to start prototyping with the Xero MCP Server, Agentic SDKs, and Prompt Library.

The future of the ecosystem: Good judgment in the age of vibe coding was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whether you’ve already started drafting your application for the Xero Global App Awards 2026 or you’re still pulling together your standout applications, there’s one unique category where the judges don’t get a say.

Instead, it is entirely in the hands of the people who know your product best: your users.

Welcome to the People’s Choice Award.

It’s all about your community

The People’s Choice Award celebrates the apps that have won the hearts of the Xero customers. It’s an incredible opportunity for advisors, accountants, bookkeepers, and small business owners to publicly recognise the tools that bring peace of mind, save them hours of manual work, and make a massive difference in their day-to-day operations.

Because our finalists are shortlisted based on receiving the highest number of unique nominations, you can’t win this one alone. The secret to success? Run a campaign through your own channels and ask your loyal network of users to back you.

We’ve built your promotion toolkit 📣

You don’t need to spend hours designing assets or sweating over copywriting from scratch. We want to make it as easy as possible for you to rally your community, so we’ve put together a plug-and-play 2026 Promotion Toolkit.

Inside, you’ll find everything you need to hit the ground running:

• a ready-to-send customer email template
• newsletter blurbs you can personalise
• pre-drafted social posts
• graphics and assets to help your app stand out

👉 Start your People’s Choice campaign here

Don’t forget the other global categories

While your customers are busy handling your People’s Choice nominations, don’t let your momentum stop there. You can still submit your own application for our core, expert-judged global categories to unlock that massive trust signal for Xero’s 4.4 million subscribers:

• Practice App of the Year: For apps that empower accounting and bookkeeping practices with meaningful, transformative impact.
• Small Business App of the Year: Celebrating the tools that help small businesses thrive and make operational life easier.
• Emerging App of the Year: Recognising early-stage apps displaying high potential and strong regional traction.
• Innovation App of the Year: Honouring bold, breakthrough ideas that fundamentally change how work gets done.
• Development Partner of the Year: Recognising the incredible builders and developers expanding the capabilities of the Xero platform.

👉 Submit your core category application here

To ensure a completely fair process, individuals can only submit one vote total. To prevent conflicts of interest, representatives, contractors, or employees of an app company cannot nominate their own app. Xero-owned apps and bank feeds are also excluded from eligibility.

The clock is ticking down to 10 July 2026. Now is the perfect time to polish your entry, download your toolkit, and get your community talking. We can’t wait to see who they choose!

Rally your community: The Xero People’s Choice Award 2026 is officially in your hands was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

OCR can read an invoice. E-invoicing can deliver cleaner invoice data.

But neither answers the question that matters when a bill reaches Xero: how does this buyer want it coded?

That gap appears when one supplier invoice contains several accounting intents. The invoice describes what was bought. The buyer’s Xero setup defines how it should be treated.

A useful implementation pattern is to add a buyer-side accounting intent layer between extraction and the Xero API. In BillBjorn, this is the role of AutoCode: an AI matcher compares extracted invoice lines with buyer-defined category hints, then maps the selected category to Xero-ready outputs.

One invoice, three accounting intents

Imagine a cafe receives this supplier invoice:

The supplier sees one invoice. The buyer may want three different accounting outcomes:

The coding decision comes from the buyer’s Xero chart of accounts, tax setup, tracking categories, and preferences. Delivery may map to Freight for one buyer and COGS for another.

Where default coding stops working

A default account per supplier works when invoices are consistent.

Multi-account invoices are harder. A fixed amount split works only when the invoice is predictable: code $10.00 to Freight and the rest to Food. When the supplier charges $17.50, $22.00, or waives delivery, the rule no longer reflects the bill.

Percentage splits break when the invoice mix changes. Split-by-tax breaks when categories share the same tax treatment. Keyword lists break when descriptions drift.

A Food category should not need a long exact-match list for coffee beans, milk, bread, produce, catering, sandwiches, and supplier-specific variations. Mixed invoices need semantic interpretation inside buyer-defined constraints.

Structured invoice data is not enough

E-invoicing improves invoice exchange. It gives developers structured fields for supplier, buyer, invoice number, dates, line items, tax, and totals.

But structured data still does not resolve buyer-side accounting context. An e-invoice may say:

It does not know whether this buyer wants that amount coded to Freight, COGS, a reimbursable expense account, or a tracking category. Clean line-item data is the input. Accounting intent is still buyer-specific.

The constrained AI matching pattern

AutoCode rules define the buyer’s allowed accounting categories and provide an AI Matching Hint for each one:

The hint describes meaning, not an exhaustive keyword list. Because the AI matcher compares meaning rather than exact text, it can categorise new invoice descriptions. “Arabica beans”, “milk for coffee”, or “bread rolls” can still match Food if they fit the category hint.

A practical design is two-stage: extract invoice lines first, then match those lines against the buyer’s configured category buckets.

The AI matcher returns user defined categories, not accounting guesses:

That is safer than asking AI to invent final Xero coding in one step.

Keep the guardrails visible

The safe behaviour is not to guess. If a line such as “service charge” does not clearly belong to Food, Packaging, or Freight, keep it as an exception:

That creates review-by-exception instead of silent miscoding.

Map intent to Xero-ready lines

Once invoice lines are matched, the accounting layer maps each category to the customer’s Xero-connected setup: account code, tax type, tracking options, description, and amount.

This separates intent from implementation:

In BillBjorn, that separation keeps AI matching constrained by the buyer’s configured categories while still producing review-ready bill lines for Xero.

Takeaway

The next useful invoice automation layer is constrained interpretation: extracted invoice data, buyer-defined category hints, semantic matching, Xero-connected accounting defaults, and human review for exceptions.

The important design choice is to let AI classify within configured accounting boundaries, then let deterministic mapping produce the Xero API payload.

Invoice data tells you what happened. The buyer’s accounting setup tells you how it should be coded.

Guest blog: Adding an accounting intent layer between OCR and the Xero API was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.

You probably heard we’re bringing Xero Developer Days back in 2026, this time, in two cities. London on 7 July (alongside Xerocon London on 8–9 July) and Denver on 18 August (alongside Xerocon Denver on 19–20 August). We’re also running a hackathon in London in the lead-up to DevDay.

That’s a lot more happening, in a lot more places. So we’re giving the Xero Developer Discord server a refresh to match. You can join via the link here.

What’s changing

Last year’s Discord was built around a single event in Brisbane. This year, the same server now needs to support three: a hackathon, DevDay London, and DevDay Denver. We’ve reorganised the channels so you can find what you need without scrolling through chatter that doesn’t apply to you.

Here’s what’s new:

• A dedicated hackathon space with channels for technical support and general information
• Combined DevDay channels that cover both London and Denver, so you can participate whether you’re following along remotely or attending in person
• Forum-style channels for hackathon support and team formation, along with a show and tell, so information doesn’t get lost in the shuffle

Who the Discord server is for

If you’re attending any of the 2026 events in person, the Discord is where you’ll get logistics updates, meet other attendees beforehand, and access key information afterwards. If you can’t make it in person, the server is your way to follow along virtually, ask questions, and stay part of the conversation.

The server also stays active all year round meaning you don’t need to wait for an event to drop in, share what you’re building, or ask the team a question.

How to join the Discord Server

If you’re already in last year’s server, you don’t need to do anything, the new structure is already there waiting for you. Just head back in!

If you’re new, you can join via the link here. You’ll be asked a couple of questions and prompted to agree to our community guidelines before you’re let in. Once you’re through, introduce yourself, and have a look around.

We’ve got a big few months ahead and we’re looking forward to having you come along for the ride.

A bigger Discord for a bigger year: revamping the Xero Developer Day server was originally published in Xero Developer on Medium, where people are continuing the conversation by highlighting and responding to this story.