Let's connect
Oops! Something went wrong while submitting the form.
Most AI training for finance teams looks the same. Someone shows how a tool can summarize a document. Everyone nods. Then the team goes back to the close process and nothing changes.
A hackathon is the opposite of that. It’s time-boxed, hands-on, and built around your team’s actual problems. The finance leaders who’ve run one well come away with 2 things: a working prototype and a much clearer picture of where AI actually fits in their work.
Here’s how to do it.
A hackathon is an event where a small group builds something instead of sitting through slides. For finance teams, that means picking a real workflow problem and spending 1–2 days using AI tools to build a working solution around it.
The output doesn’t need to be polished. It needs to be real enough that your team can react to it.
Finance hackathons differ from generic ones in 2 ways. The use cases are narrower (think reconciliation and variance commentary, not general brainstorming). And the guardrails are tighter, because financial data requires it.
Reading about AI is not the same as using it. Most finance leaders know technology is changing their work. Fewer have a structured way to find out what’s actually useful for their specific team and workflows.
A hackathon solves that. It compresses months of “we should try this someday” into 1-2 days of building and testing with real problems.
The teams that never experiment fall behind. The ones that experiment without structure burn time and goodwill on tools that don’t stick. A well-run hackathon avoids both.
The most common mistake: starting with the tool. “Let’s see what ChatGPT can do” is a recipe for a fun afternoon that produces nothing your team will actually use.
Start with a short list of pain points instead. What slows your month-end close? What does leadership ask for every quarter that requires a manual data pull every time?
Pick 1–2 of those problems. Build your hackathon around solving them.
This keeps the event grounded. You’re asking whether AI can solve a problem your team already has. That’s a much more honest test than “what can this tool do?”
Some AI applications are well-suited to a first hackathon. Others need months of IT involvement before they’re viable. The difference matters.
Good starting points:
• Variance commentary. Draft narrative for board packages or management reports using structured data. Low risk, immediate time savings.
• Reconciliation exception summaries. Use AI to flag and explain exceptions instead of reviewing line by line.
• Close checklist tracking. Turn manual status tracking into something AI monitors and surfaces automatically.
• Internal policy Q&A. Build a tool that lets your team ask questions about vendor contracts or accounting policies without digging through shared drives.
Keep your first hackathon away from payroll and public financial reporting. Those areas carry real consequences if an AI-generated output gets used without proper review.
Most hackathon guides skip this section. Don’t.
Before anyone opens a laptop, your team needs clear answers to 4 questions.
Anonymized test data is the starting point. Actual financial statements or customer data needs IT and legal sign-off before it’s in scope. “Sensitive data” is too vague. Be specific.
Your IT and security teams should have a list of cleared AI platforms. If they don’t, building that list comes before the hackathon.
Clarify ownership and retention of anything generated during the event. This is easier to decide before the day than after.
Yes. Always. Build that expectation into the structure of the day from the start, not as an afterthought.
These rules exist to make the hackathon safe enough to actually run. Skipping them is how you end up with a data governance problem instead of a prototype.
Most teams skip this planning step entirely. They block off a morning, invite the whole department, and wonder why they ended up with a list of ideas instead of a working prototype. Three decisions made before the day starts determine whether the event produces something real.
Commit to a full day — 6 to 8 hours. A half-day produces half-baked results. The first hour is always orientation and setup. You need enough runway for teams to hit a wall, work through it, and come out with something you can react to.
A workable single-day structure:
• 9–11 am: Problem framing and team setup. Review the 1–2 use cases you pre-selected. Assign teams. Confirm the data and tool guardrails everyone agreed to beforehand. One framing that works well here: ask everyone to finish this sentence before building anything: “I really hate when I have to [task] every week. How can I get AI to do it for me?” That question surfaces the small, recurring frustrations that are often the easiest wins. Not every prototype needs to solve a large workflow problem. Some of the best hackathon outputs come from eliminating a 20-minute daily task that nobody thought was worth fixing. You can pursue the big case studies too, but the small ones are where momentum gets built and the best place to start=.11am–2pm: Build time. Teams work on their prototypes. Have someone available to answer questions and unstick blockers — not to direct the work.
• 2–3 pm: Checkpoint. Not a formal presentation — just a quick temperature check. Teams share rough progress. This surfaces blockers early and keeps momentum from dying in the afternoon.
• 3–5 pm: Polish and demo prep. Teams finalize their prototypes and prepare a 5-minute demo. Keep the format tight. You’re showing it works, not selling a product.
• 5–6 pm: Demos and debrief. Each team presents. Capture every idea, including the ones that didn’t fully work. The debrief is where you decide what’s worth taking further.
For a first hackathon, depending on the size of the organization, 10 to 20 people across 3 to 5 teams is the right size — manageable enough to run well, large enough to produce more than one idea worth pursuing. Each team should have 3 to 5 people. For smaller organizations, 3-5 people per group is a good rule of thumb.
Don’t make it finance-only if you can help it. The strongest teams pair finance and accounting staff who own the actual problem with at least one person from IT or operations who can help when tools misbehave. That said, not every organization can put an IT person on every team, or in the room at all. If that’s your situation, it’s fine. An accounting team can still run a productive hackathon without dedicated IT support. What helps is having one technical resource available to roam between teams and field questions as they come up, even if it’s just someone comfortable troubleshooting a prompt or connecting an output to a spreadsheet.
--> One accounting team ran their event with 50+ participants and came away with 9 working automation solutions, saving 100+ hours a month. The key was preparation, not headcount.
Roles matter more than titles. Finance and accounting staff define the problem and validate whether the output is accurate — they’re the ones who know when a number looks wrong. IT or operations handles setup friction and tool configuration. A manager or team lead makes real-time decisions about scope, so teams don’t spend an hour debating whether a use case is in bounds. Keep those roles explicit from the start of the day.
At the end of the day you’ll have 3 to 5 rough prototypes. Rate each one on two dimensions: time savings potential and implementation difficulty. The ones that score high on both move forward. Assign an owner to each and set a 30-day deadline for a parallel pilot — not a full rollout, just a side-by-side test against your current manual process.
Document the current manual step. Run the AI-assisted version in parallel for 2 to 4 weeks. Compare outputs with a human reviewer. Only replace the manual process after your reviewer confirms that the AI version is consistently reliable. This is especially important in finance, where an error in an AI-generated output can have downstream consequences before anyone catches it.
This is where most hackathons fail. The demos happen, everyone agrees it was interesting, and nothing changes. The 30-day pilot with an assigned owner is the mechanism that turns “we built something” into “we changed how we work.”
Schedule a recurring 30-minute session every two weeks — open to anyone on the finance and accounting team — where people can share an AI tool they’ve been using, a prompt that saved them time, a prototype they’re testing, or something they’re just curious about. No formal agenda. No polished slides required.
This does two things. It keeps experimentation alive between hackathons instead of letting it stall after the initial event. And it creates a low-pressure way for less confident team members to learn from peers who are a few steps ahead — which is often more effective than any formal training. The hackathon plants the seed. Show and Tell is how it grows.
-------------
Finance teams that run hackathons well come away with something most AI initiatives don’t produce: proof. Proof that a specific tool, on a specific problem, saves your team real time. That’s a far better foundation for rolling AI into your workflow than a vendor demo.
------------
At CX, AI adoption isn’t a training session, it’s part of how our professionals work.
Our professionals are equipped with AI tools that help them deliver accurate, quality work and move faster on the workflows that matter. That means when a CX professional joins your team, they’re already working the way finance is heading, not catching up to it.
That matters because the hardest part of AI adoption in finance isn't the technology. It's having people who know which outputs to trust, which to verify, and which to leave alone entirely. Our professionals arrive with that judgment already developed.
It’s one more reason CX professionals integrate quickly and contribute from day one.
Ready to bring that into your team? Reach out at infocx@connorgp.com
