From Spreadsheet to Enterprise APEX System with AI
Introduction
This is not another post about creating an APEX app from a spreadsheet using the Create app Wizard. This post is about using AI to design and accelerate the build of an enterprise APEX system from a spreadsheet.
Background
A client recently asked me to build an APEX system to replace their existing spreadsheet-based expenses system. The goals were clear:
Reduce the time from expense submission to payment
Improve the accuracy of taxes calculated for expenses
Allow management to track expenses
Reduce errors caused by manually entering AP invoices into Oracle E-Business Suite
Improve anomaly detection
Improve user experience
The company’s expense rules were already embedded in the Excel template. The template included formulas for mileage reimbursement, Canadian tax calculations, and finance summaries used to enter AP invoices into Oracle EBS.
An AI First Approach
One of my goals for 2026 is to adopt an AI-first approach. It will not always work, but using it as the default starting point is helping me understand its limitations and get much more out of it.
One word of caution. Just because AI cannot do something well today doesn't mean it won't be able to when the next frontier model is released. It is important that we regularly re-evaluate our perceptions of what AI is capable of.
Architecture
At this stage, it is worth describing the client's APEX environment. They have an on-premises APEX instance running on the Oracle e-Business Suite (EBS) instance. This sits behind a firewall accessible only via VPN. They also have an OCI APEX Service instance running externally-facing APEX apps. The plan was to have expense report entry and approval run in the OCI instance, and then pull approved expense reports into the on-premises EBS instance for review and payment in Accounts Payable by finance.
OCI owns the approval state of the expense reports
EBS owns the payment state of the expense reports
SharePoint owns receipt attachments
Design
Business Rule Extraction
The legacy expense report Excel template's tabs, tables, fields, and formulas essentially contained all the business rules. I started the design phase by asking Codex to analyze the Excel template and draft a Product Requirements Document (PRD) based on it. Codex produced a four-page Markdown PRD covering the business rules, entities, fields, data types, and lists of values.
Verification
I took the PRD and asked Codex to review it against business best practices and current Canadian tax rules. It augmented the design with rules not already in their spreadsheet. For example, Codex suggested additional mileage-rule considerations that were not explicit in the spreadsheet, which we then validated against current Canadian guidance and the client’s reimbursement policy.
User Interface
I then asked Codex to create graphical wireframes of the APEX pages needed for the solution. I attached several screenshots from existing APEX apps, so it could match the corporate look and feel. Codex created the wireframes using real data from an old expense report Excel. I incorporated screenshots into the design document.
Business Review
I then reviewed the PRD with business users to get their feedback. Being able to present the business rules in a clearly laid out document (instead of embedded in Excel formulas), and being able to show them what the new app was going to look like was significant. We made some minor updates to the design based on feedback from this review.
At this stage, we had an approved design document and a clear path forward after only 10 hours of effort.
Build
Using Codex, I attached the approved design document and provided an extensive prompt detailing what I wanted it to do. I split this into two prompts, one for the OCI expense entry side of the app (running on OCI) and a separate one for the on-premises side of the app. Each prompt requested:
A comprehensive data model.
Secure views and views that abstract table-join complexity from APEX.
PL/SQL utility packages with APIs to manage email generation, REST integrations, workflow functions, and managing attachments in SharePoint.
ORDS APIs to allow the On-Premises EBS environment to fetch approved expenses for payment, and to post back to let employees know when their expenses have been paid.
Along with the prompt, I included:
Sample tables from previous apps to teach the model the table creation standards.
PL/SQL code from previous apps that had APEX workflow approvals and that used a SharePoint attachments common package that we use.
An
AGENTS.mdfile to provide product versions, coding standards, formatting standards, etc.
The outcome was:
A roughly 90% complete data model with foreign keys, constraints, appropriate data types (and sizes), and comments.
Scripts to load the current tax and mileage rates from the template Excel into the new tables.
Abstraction of Canadian Provinces and Territories into Jurisdictions applicable to mileage and tax rates, which is something I would not have thought of.
Cloud and On-Premises PL/SQL packages with the helper procedures and functions that I requested.
A SQL script to create an ORDS OAuth2 Credential, ORDS module, privilege, templates and handlers.
Twenty unit test scripts to test both sides of the app.
There were a few issues which were resolved with another hour or so of follow-up prompts and clarifications.
APEX
All that was left was to build the APEX app. This part was less fun because, at the time of writing in March 2026, APEXlang was not yet available. Frankly it took longer to build the APEX app than all of the other artifacts created up to this point.
Overall, I would estimate that what would normally have been an 80-hour project was reduced to about 40 developer hours with the help of AI. We will have to see how much lower this can go when APEXlang comes along.
Keys to Success
The following points were key to the success of this project:
90% of the business rules were explicitly baked into the Expense Report Excel. This made it easy for the AI to extract the rules and for us to verify it had done it accurately.
Presenting the business with a PRD within a few days of starting the project (with realistic wireframes) inspired confidence that we are heading down the right path with minimal investment of time.
Splitting the build phase between on-premises and OCI allowed the model to focus on each build separately and reduced the risk of confusion between the different database versions, APEX versions, and EBS-specific coding standards.
Models respond really well to examples. Pointing AI to a package and saying "create a procedure to do X that follows the same pattern as procedure Y from another package" works very well.
Being specific about the output you expect is also key. For example, you need to specifically request test scripts, and request that they include edge cases as well as happy path tests. Combine this with SQLcl and its MCP server, and you can prompt the AI to run the test suite after every change.
Conclusion
AI did not build this system on its own, but it removed a large amount of the slow, repetitive work at the start of the project. The spreadsheet already contained most of the business rules. AI helped extract those rules, turn them into a usable design, and generate much of the database and PL/SQL foundation.
The real value was speed and clarity. We were able to review a proper design with the business early, make corrections before build started, and cut the overall development effort significantly. The parts that still needed the most hands-on work were the APEX application itself, validation of the generated output, and the final handling of edge cases.
For this type of project, AI worked best as a force multiplier, not as a replacement for experience. It was useful because the source material was structured, the prompts were specific, and every output was reviewed before being used.
