Finance Systems Integration

The stack at a glance

If you take nothing else from this chapter, take this table — you should be able to recite it cold.

A simple mental model: Fireblocks holds the crypto. Lukka accounts for it. Banks hold fiat. Kyriba positions it. NetSuite books both. BlackLine reconciles everything to NetSuite.

NetSuite — the General Ledger

The book of record. Every journal entry, every account, every entity rolls up here.

Things to know cold

• Chart of accounts (CoA): hierarchical account structure. Large orgs run thousands of accounts × multiple subsidiaries.
• Subsidiaries & consolidation: NetSuite OneWorld handles multi-entity. Consolidation involves elimination entries between intercompany pairs.
• Periods: monthly fiscal periods. Periods get closed — once closed, posting requires period re-opening (a control event).
• Subledgers: AR, AP, fixed assets feed the GL.
• SuiteTalk REST: modern REST API. SuiteQL: SQL-like queries against NetSuite data.
• Rate limits: real. Plan for pagination, retries, and async patterns.

What agents do against NetSuite

• Read trial balance, journal entries, transaction details.
• Propose journal entries (write to staging table, never direct post).
• Read CoA for prompt context.
• Read subledger detail for reconciliations.

BlackLine — the reconciliation engine

The system that runs your monthly close discipline. If NetSuite is the books, BlackLine is the close project manager.

What it does

• Account reconciliations: every balance-sheet account has a recon owner. BlackLine tracks status, holds supporting docs, runs matching rules.
• Close task management: 80+ tasks per close, owners, dependencies, deadlines.
• Journal entry workflow: route JEs for approval before they hit NetSuite.
• Certification: monthly attestation that an account is reconciled and correct.
• Variance analysis: flux explanations period-over-period.

Why agents love this

BlackLine is structured, auditable, and process-aware. An agent that produces a recon can hand it to BlackLine's workflow rather than reinventing approvals. The Process Owner concept aligns naturally with BlackLine's recon-owner concept.

Risks

BlackLine has its own matching rules and connectors. If your agent and BlackLine both try to match the same transactions, you'll create double-matching bugs. Decide the boundary up front: typically, agent handles the "long tail" (the items BlackLine's rules can't match) while BlackLine handles the bulk auto-match.

Kyriba — treasury management

The cockpit for cash and liquidity. Aggregates bank balances, manages payments, handles FX exposure, runs cash forecasts.

Things to know

• Bank connectivity: SWIFT, BAI, MT940, EBICS — file formats and protocols that move banking data.
• Cash positioning: real-time view of where the company's cash is, across banks and accounts.
• Sweeps & ZBA: automated movement of cash to concentration accounts (zero-balance account, or sweep to a money-market fund / MMF).
• FX exposure: net positions by currency; hedging workflow.
• Payment factory: standardized payment generation and approval.

What agents do against Kyriba

• Treasury monitoring agent: read cash positions, flag thresholds, alert.
• Sweep-suggestion agent: propose movements; human approves.
• Forecast assistant: pull historical patterns, propose forecast updates.
• FX exposure summary for treasurer's daily review.

Fireblocks — crypto custody

Institutional crypto custody using MPC (multi-party computation) wallets. Fireblocks holds the keys, signs transactions, enforces policy.

Things to know

• Vaults & wallets: organizational units holding assets. Multiple asset types per vault.
• Policy engine: rules about who can sign what, when, with how many approvers, to which destinations (whitelists).
• Transaction lifecycle: queued → policy-checked → signed → broadcast → confirmed on-chain.
• API + webhooks: pull balances, push transaction notifications.
• AddressBook: known counterparty addresses with classification.

For Finance specifically

The Finance side cares about balances and transactions, not the cryptographic signing. Fireblocks is your source of truth for "what does the company hold on-chain?" — which Lukka then turns into accounting entries, which NetSuite books.

Lukka — crypto subledger & fair value

The least familiar system for most candidates and the most distinctive piece of a crypto-native finance stack. Spend an extra five minutes here.

What Lukka does

• Crypto subledger: takes raw on-chain and exchange data, produces accounting-grade ledgers (lots, cost basis, gains/losses).
• Fair value: principal-market fair value of digital assets at any timestamp — critical for FASB ASU 2023-08 (Crypto Assets fair value).
• On-chain reconciliation: ties internal records to blockchain reality across many chains.
• Tax & regulatory reporting: jurisdiction-specific outputs.

Why this is hard

Crypto accounting has problems traditional accounting doesn't:

• Many chains, each with their own transaction model (UTXO vs. account-based).
• "Internal" transfers between own wallets are not taxable events but look like transactions.
• Fair value can move minute-to-minute; the timestamp policy matters.
• Lot selection (FIFO/HIFO/specific ID) drives reported gains/losses.
• Wrapped tokens, staking rewards, airdrops — each is a distinct accounting event class.

Lukka exists so you don't reinvent this. The agents do not redo Lukka's work; they consume Lukka outputs and reconcile to NetSuite.

Data flows across the close cycle

The shape, drawn on a whiteboard:

    Banks ──────► Kyriba ─────────► NetSuite (Cash entries)
                                          ▲
    Blockchain ──► Fireblocks ──► Lukka ──┤ (Crypto subledger → GL)
                                          │
    Exchanges ─────────────────► Lukka ───┘
                                          ▲
                                          │
                                    BlackLine
                                  (recons GL vs.
                                   source systems)
                                          ▲
                                          │
                                  Agentic Layer
                            (proposes JEs, narrates,
                             flags anomalies, executes
                             checklists, runs evals)
  

Two important reading directions:

• Bottom-up: real-world events (a bank deposit, an on-chain transfer) flow up into systems-of-record and eventually into NetSuite as journal entries.
• Top-down (reconciliation): BlackLine and your agentic layer compare NetSuite balances against source-system balances and flag breaks.

First-principles stack evaluation

This is the architect question, and the JD asks for it explicitly. The framework:

1. What is each system's irreducible job? Strip features, what's the core function? NetSuite = GL. BlackLine = recon workflow. Etc.
2. Where do systems overlap? BlackLine and NetSuite both have JE workflow. Kyriba and bank portals both have balance views.
3. Where are the integration gaps? Manual exports/imports, spreadsheets in the middle, custom scripts no one owns.
4. What does an AI-native target look like? Agentic layer as system-of-action; systems-of-record stay; some workflow tools (e.g., BlackLine task management) potentially get replaced by agent-driven workflows.
5. What's the migration path? Run the agentic layer alongside. Replace specific workflows piece by piece. Sunset overlapping features only when the agent layer has proven equivalent controls.

The senior answer is not "rip out BlackLine." It's: "BlackLine's matching rules and recon workflow are mature; the agentic layer adds value on the long tail and on cross-system orchestration. Three years out, the agentic layer might absorb close task management; the recon engine stays."

API integration patterns

You'll be asked about the practical realities. Cold-knowledge:

Skeleton: a hardened NetSuite client

import httpx
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type

class NetSuiteClient:
    def __init__(self, base_url, auth, timeout=30):
        self.client = httpx.AsyncClient(base_url=base_url, auth=auth, timeout=timeout)

    @retry(
        stop=stop_after_attempt(5),
        wait=wait_exponential(multiplier=1, min=1, max=30),
        retry=retry_if_exception_type((httpx.TimeoutException, httpx.HTTPStatusError)),
        reraise=True,
    )
    async def suiteql(self, query: str, params: dict | None = None) -> list[dict]:
        r = await self.client.post("/services/rest/query/v1/suiteql",
                                   json={"q": query, "params": params or {}})
        if r.status_code == 429:
            raise httpx.HTTPStatusError("rate limit", request=r.request, response=r)
        r.raise_for_status()
        return r.json().get("items", [])

The agentic layer on top

The target architecture from the JD: "Build an agentic finance layer that runs alongside the existing stack today, automating workflows while defining the migration path toward a more scalable, AI-native architecture over time."

Concretely, you'll build:

• One MCP server per system: netsuite-mcp, blackline-mcp, kyriba-mcp, fireblocks-mcp, lukka-mcp. Each exposes a narrow set of read tools and explicitly-named staging-write tools.
• A shared identity / audit layer: every tool call carries caller identity, workflow run id, idempotency key.
• A library of workflow templates (n8n + Python): bank rec, intercompany rec, on-chain rec, treasury monitor, close checklist, accruals proposal.
• A central eval harness (chapter 07) measuring each workflow's correctness over time.
• A governance dashboard: every active automation, its tier, its Process Owner, its last eval pass, its uptime.

That last bullet is the foundation called out in the JD's fifth responsibility area. Build it early; it's the artifact that makes you "platform" rather than "scripts."