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."

✓ Check yourself

Answer from memory before opening each one.

1. The NetSuite balance for a crypto asset is 12 units lower than the Fireblocks vault balance. Which systems do you compare, in what order, and which direction is the reconciliation?

   Show answer

   Fireblocks holds the assets, Lukka turns on-chain activity into the subledger, and NetSuite books the result. Reconcile top-down, from the NetSuite balance against the Lukka subledger and then against the Fireblocks vault, to find the layer where the 12 units appear. A break is usually a timing or classification difference at one hop. See data flows.

2. Your agent and BlackLine's rules both try to match the same bank lines. What goes wrong, and how do you set the boundary?

   Show answer

   Items get matched twice, once by each system, and the counts and balances stop agreeing. Let BlackLine's mature rules auto-match the bulk, and point the agent at the long tail they cannot match. Agree that boundary up front, not after the first double-match. See BlackLine.

3. A colleague suggests the agent should compute crypto fair value itself from exchange prices, since the model is good with numbers. Why is that the wrong place for the work?

   Show answer

   Fair value depends on the principal market, the timestamp policy and lot selection, and those choices drive reported gains and losses. Lukka exists to apply them consistently, and a model that recomputes them produces a second, unauditable answer. The agent consumes Lukka's output and reconciles it to the ledger. See Lukka.

4. Leadership asks whether you would replace BlackLine. How do you answer from first principles?

   Show answer

   Strip each system to its irreducible job, find the overlaps and gaps, and migrate only when the agent layer has shown equivalent controls. BlackLine's matching and recon workflow are mature, so the agent adds value on the long tail and cross-system orchestration, and task management is the part most likely to move over time. See first-principles evaluation.

5. Fireblocks delivers the same transaction webhook twice, ten seconds apart. What does your handler need to do so the books stay right?

   Show answer

   Verify the signature first, then process the event idempotently, keyed on the transaction identifier, so the second delivery is recognised and does nothing. Webhooks are at-least-once, so a handler that mutates state per delivery will double-record. See API integration patterns.

6. You can build one piece of the agentic layer first: the NetSuite MCP server or the governance dashboard of tiers, owners and eval status. Which first, and what changes the answer?

   Show answer

   Usually the MCP server, because every workflow needs the ledger and the audit and identity fields ride on it. Build the dashboard as soon as the second automation exists, since an inventory of tiers and owners is what makes the layer a platform. If auditors or the CoE are asking for an inventory now, the order flips. See the agentic layer.

Takeaway

• Each system has one job: NetSuite is the ledger, BlackLine runs reconciliation and close, Kyriba positions cash, Fireblocks holds crypto, and Lukka accounts for it.
• Events flow bottom-up into the ledger, and reconciliation reads top-down, comparing ledger balances to source systems to find breaks.
• Agents propose and read, and they never post. Production writes stay behind the system's own workflow and a human approver.
• Decide the boundary with BlackLine early: its rules take the bulk of matching and the agent takes the long tail.
• Lukka owns crypto subledger and fair value. The agent consumes its output instead of recomputing it.
• The senior answer on the stack is to run the agent layer alongside, prove equivalent controls, then retire overlap piece by piece.
• Integrations need pagination, jittered backoff on rate limits, idempotent writes and handlers, signed webhooks, and pinned API versions.

With the systems and the agent layer mapped, the next chapter specifies the concrete agents that run on top. → Applied Patterns

Further reading

• Overview of SuiteTalk REST Web Services — Oracle NetSuite documentation. The REST API surface and its record model.
• SuiteQL — Oracle NetSuite documentation. The SQL-like query language used for reading ledger data.
• API Overview — Fireblocks developer docs. Authentication and the shape of the API.
• ASU 2023-08: Accounting for and Disclosure of Crypto Assets — FASB, 2023. The fair value measurement rule that drives the subledger.
• MCP tools — Model Context Protocol project, 2025. How a server exposes tools to an agent.
• Timeouts, retries and backoff with jitter — Amazon Builders' Library. Backoff design for rate-limited APIs.