Jira, GitHub blurred capitalization; mapped epics/commits to Oracle Financials Cloud journals with controller sign off

Overview

A fintech needed consistent capitalization of software development costs, but engineers logged time in Jira and coded in GitHub without financial context. Finance reconstructed support each close, debates over what qualified under policy were ad hoc, and journals in Oracle varied by project. Intelligex connected Jira and GitHub to a finance?governed classification engine, generated capitalization entries in Oracle with linkbacks to epics and commits, and required controller sign?off for borderline items. Entries reflected actual work, documentation supported policy, and discussions moved from opinion to structured review—without changing product tools or the ERP.

Client Profile

• Industry: Financial technology (platform and services)
• Company size (range): Multi?product organization with distributed engineering teams
• Stage: Jira for planning, GitHub for source control and CI/CD, Oracle for ERP; cost capitalization handled via spreadsheets and manual review
• Department owner: Finance & Accounting (Technical Accounting and Controllership)
• Other stakeholders: Engineering, Product Management, HR/Payroll, Procurement/Vendor Management, Internal Audit, Legal/Compliance, IT/Integrations

The Challenge

Engineering work spanned discovery spikes, new feature builds, refactors, fixes, and post?release support. Time entries referenced Jira issues or epics inconsistently, and commit histories and pull requests lived only in GitHub. Finance needed to distinguish preliminary project activities from application development and post?implementation work, but there was no common taxonomy in engineering tools to make that decision repeatable. Period?end relied on spreadsheets, interviews, and rough percentages, and journals were supported by screenshots and email.

Contractor costs added complexity. Statements of work used engineering language, invoices referenced project names or repositories, and coding to capital or expense varied by buyer and project. Disputes over refactoring, bug fixes close to release, and long?running tech debt work consumed review time. Internal and external reviewers asked for evidence that capitalized costs aligned with policy, but links between entries and engineering artifacts were rebuilt every period.

Why It Was Happening

Root causes were fragmented signals and an absent policy layer in the systems of work. Jira held intent, GitHub reflected execution, HR/Payroll carried rates and cost centers, and Oracle posted journals—but there was no governed model that mapped engineering activity to capitalization policy with traceable evidence. Engineering teams labeled work for delivery, not accounting treatment, and the same type of activity appeared under different issue types or repository conventions across teams. Finance translated post?hoc, which led to inconsistencies and rework.

Ownership and timing were misaligned. Engineering moved quickly and changed scope mid?sprint, Finance reviewed monthly, and Procurement processed contractor invoices on their own cadence. Without an automated pipeline and decision rules, borderline calls hit close deadlines and approvals lived in email instead of in a durable trail tied to the ledger.

The Solution

Intelligex implemented a capitalization pipeline that joined Jira and GitHub activity to a finance?governed classification engine. Jira epics and issues, GitHub commits and pull requests, and time entries were normalized to a canonical schema and evaluated against policy rules for preliminary, application development, and post?implementation phases. Labor costs and eligible contractor invoices were mapped accordingly, proposed journals were generated for Oracle, and any borderline items entered a controller approval queue with side?by?side evidence (epics, PRs, release tags). Policy references aligned with internal interpretations of guidance such as ASC 350 (internal?use software) and IAS 38, while Jira, GitHub, and Oracle remained the systems of record.

• Integrations: Jira issues and worklogs via the Jira Cloud REST API; GitHub commits, pull requests, and releases via the GitHub REST API; HR/Payroll rates and cost centers; contractor invoices and POs; journal creation in Oracle Financials Cloud.
• Canonical engineering schema: Standard fields for project, epic, issue type, status, timestamps, pull request link, release tag, worklog hours, contributor, cost center, and repository; effective dating for policy versions.
• Policy classification engine: Finance?owned rules for preliminary vs. application development vs. post?implementation, with signals from issue types/status, PR merge to release branches, and proximity to GA; exceptions for refactor vs. new module, migration, and remediation work.
• Labor and vendor mapping: Hourly cost from HR/Payroll, loaded by cost center and contributor; contractor invoice line mapping to projects/epics with attachment of SOW excerpts; duplicate and overlap checks.
• Journal generation: Proposed capitalization and expense journals by project and entity, with linkbacks to evidence; safeguards to avoid double counting across periods; preview diffs for reviewers.
• Maker?checker workflow: Controller review for borderline classifications and high?impact entries; reason codes and comments required; approvals and overrides immutably logged.
• Dashboards: Views of capitalizable activity by project and team, exception aging, rule impact, contractor coverage, and period posture; drill?downs to epics and PRs.
• Audit trail: Lineage from journal lines to Jira/GitHub artifacts, policy version applied, and reviewer decisions; exportable evidence packs.

Implementation

• Discovery: Cataloged engineering workflows, Jira configurations, and GitHub branching/release practices; inventoried current capitalization decisions, borderline patterns, and contractor invoicing; reviewed policy interpretations and audit comments; mapped Oracle posting structures.
• Design: Defined the canonical schema and identity keys across Jira, GitHub, HR/Payroll, and Oracle; authored classification rules and escalation criteria under change control; specified vendor invoice mapping patterns; designed journal templates, approval gates, and dashboards.
• Build: Implemented Jira and GitHub collectors; developed normalization and join logic; built the policy classification engine and unit tests; integrated HR/Payroll cost data and contractor invoice mapping; created journal generators and Oracle posting; assembled approval workflows, dashboards, and evidence exports.
• Testing/QA: Ran in shadow mode: classified recent sprints and generated draft journals while Finance continued manual methods; compared outcomes to prior entries; tuned rules and signals (for example, issue type/status combinations, release tag conventions); piloted controller approvals on borderline cases with Technical Accounting and Audit.
• Rollout: Enabled journals for selected products and teams first; retained manual adjustments as a controlled fallback; expanded coverage as exception rates stabilized; tightened mandatory approvals for high?impact exceptions after training.
• Training/hand?off: Delivered sessions for Finance, Engineering, and Procurement on reading classifications, handling exceptions, and mapping contractor invoices; updated SOPs for epic hygiene, release tagging, and capitalization reviews; transferred ownership of rules, thresholds, and dashboards to Controllership under change control.
• Human?in?the?loop review: Established a monthly review to assess exception trends, rule updates, and edge cases (large refactors, cross?team migrations); decisions recorded with rationale and effective dates.

Results

Capitalization entries reflected the work actually performed. The pipeline linked epic intent, code changes, and time entries to policy, so journals were generated from consistent signals rather than from spreadsheet allocations. Borderline items—such as extensive refactors or bug remediation near release—were flagged with the relevant Jira and GitHub evidence and routed for controller decision. Contractor invoices were mapped to projects with SOW excerpts attached, and vendor lines that did not align to eligible activities were excluded with reason codes.

Reviews became faster and more defensible. Controllers focused on material exceptions and policy updates instead of reconstructing activity. Audit packs included policy version, classification rationale, and citations to epics, PRs, and release tags. Engineering kept Jira and GitHub practices, with minor hygiene updates (epic status and release tagging) to improve signal quality. Oracle remained the system of record; the addition was a governed classification and posting layer that turned engineering activity into accounting outcomes with traceable evidence.

What Changed for the Team

• Before: Capitalization relied on manual percentages and interviews. After: A rules engine classified work from Jira and GitHub with linkbacks.
• Before: Borderline calls were debated in email. After: Maker?checker routed exceptions with evidence and reasoned approvals.
• Before: Contractor invoices were coded inconsistently. After: Invoices mapped to projects and policy with SOW excerpts and controls.
• Before: Period?end support was rebuilt each time. After: Journals carried lineage to epics, commits, releases, and policy versions.
• Before: Engineering changed behavior reluctantly. After: Light hygiene (epic status, release tags) improved classification without new tools.
• Before: Audit discussions restarted from scratch. After: Evidence packs answered “what, why, and who approved” in one trail.

Key Takeaways

• Bring policy to the tools of work; classify Jira and GitHub activity under a governed model rather than retrofitting spreadsheets.
• Define a canonical taxonomy; preliminary, application development, and post?implementation need clear, finance?owned rules.
• Tie journals to artifacts; link entries to epics, PRs, and releases so reviews address substance, not data assembly.
• Govern edge cases; maker?checker with reason codes makes borderline items consistent and auditable.
• Include vendors; map contractor invoices to projects and policy with documented support.
• Integrate, don’t replace; keep Jira, GitHub, and Oracle, and add a classification and posting layer with dashboards and audit trails.

FAQ

What tools did this integrate with? Jira issues and worklogs were ingested via the Jira Cloud REST API, GitHub commits and pull requests via the GitHub REST API, and journals were posted to Oracle Financials Cloud. Policy alignment referenced concepts in ASC 350 (internal?use software) and IAS 38.

How did you handle quality control and governance? Classification rules lived under Controllership change control with effective dating. Every journal line carried the policy version applied, links to Jira/GitHub artifacts, and approval status. Maker?checker approvals were required for borderline items and high?impact entries, with reason codes and comments. All changes and postings were immutably logged.

How did you roll this out without disruption? The pipeline ran in shadow mode first, classifying recent sprints and generating draft journals while Finance continued current processes. Drafts were compared to prior entries and policy interpretations, and rules were tuned. Rollout began with selected products and teams, expanded as exception rates stabilized, and mandatory approvals were phased in after training.

What criteria drove capitalization vs. expense? The rules engine evaluated signals such as issue type and status, linkage to a defined epic or project charter, PR merges to release branches, and proximity to go?live. Work aligned to preliminary research or post?implementation maintenance was treated as expense; application development activities were eligible for capitalization. Ambiguous items (for example, refactors or remediation tied to new functionality) routed to controller review with the relevant artifacts.

How were contractor invoices treated? Contractor invoices referenced SOWs and project identifiers and were mapped to epics or modules. Lines tied to eligible application development were included; discovery or support services were excluded. When descriptions were ambiguous, the case entered the approval queue with attached SOW excerpts and any associated Jira/GitHub evidence.

How did you prevent double counting or drift across periods? The journal generator compared current period classifications to prior postings, preserved amounts already capitalized, and proposed only incremental entries. Effective?dated rules ensured consistent treatment across periods, and diffs showed reviewers what changed and why.

Did engineering need to change how they worked? Only minimal hygiene was requested: consistent epic usage for major initiatives, clearer issue statuses, and reliable release tags. The system inferred as much as possible from existing patterns, and Finance owned classification rules so engineering did not have to label work with accounting terms.