Start Excel trial

Trial contract · finance teams

30 days. One reconciliation. Your stack. Your reviewers.

The trial exists to answer one question: does YiG produce a reconciliation draft your team would actually ship? This document defines the scope, both parties' commitments, the success metrics derived from your own audit log, and the data-handling terms. Forward it to your CFO as-is.

PILOT-CONTRACT / 30-DAY SCOPE draft

Terms at a glance

Duration
30 days · 4 weekly checkpoints
Scope
One reconciliation flow (e.g. statutory × IFRS basis)
Deployment
Local install · customer VPC · single-tenant managed
Data path
Read-only · stays in your stack · BYOK inference
Cost
No charge during trial · paid extension agreed at week 4
Cohort
Capped — we onboard in waves so each team gets an attached engineer for the full 30 days

Scope

In scope

  • One reconciliation flow. Pick the recon that hurts most — statutory × group basis, GL × subledger, period-to-period version, IC roll-forward.
  • Two source connections. Anything YiG can read as a SQL view or Excel file: SAP, NetSuite, Oracle, Snowflake, BigQuery, MS Dynamics, file shares.
  • Reviewer flow in Slack Canvas or CLI. Your reviewer signs off bridge-item-by-bridge-item with slack_canvas_button_click events captured.
  • Approved output to your close folder. excel_write lands the reconciliation workbook at the path you configure.
  • Audit log forwarding. Structured records emitted via Python logging — forward to your SIEM, Datadog, or Splunk as JSON.
  • One engineer attached. A YiG engineer joins the integration call, the weekly check-in, and the production close.

Out of scope

  • Multi-entity consolidation. Trials are scoped to one entity to keep the success criteria measurable. Multi-entity opens in the paid extension.
  • Custom connectors. If your source isn't reachable as SQL or file, we'll scope a connector for the paid phase — not the trial.
  • Workflow customization beyond default skill packs. The trial proves the loop on a standard recon. Bespoke workflows are paid work.
  • Production SLA. Trials run alongside (not in place of) your existing close process. We do not sign 99.9% SLAs at the trial tier.
  • Procurement-grade pricing. Pricing for the extension is decided once we know which flows you are keeping.

Schedule

  1. W1

    Integration scoping

    Read-only access to your two sources is provisioned. YiG is installed in the deployment mode you chose. We register source DataFrames, validate the basis columns, and configure materiality thresholds together.

    Deliverable: First tool.execute.complete for finance_basis_reconcile against your real data — not a sample.

  2. W2

    First dry run + reviewer training

    We run a full reconciliation off last month's closed numbers (where the right answer is already known). Your reviewer walks the Slack Canvas / CLI / Office flow and approves/rejects bridge items against the known-correct baseline.

    Deliverable: First-pass approval rate from the dry run + a list of narrative-quality gaps to fix before the real close.

  3. W3

    First production close (parallel run)

    The real close happens. YiG drafts the reconciliation in parallel with your existing process. Your reviewer signs off line by line. Approved output lands in your close folder. Your existing process remains the authoritative book of record.

    Deliverable: Approved reconciliation workbook + complete audit log of the run, forwarded to your SIEM.

  4. W4

    Review meeting + extension decision

    We sit together with the audit-log-derived metrics. You decide: extend to a second flow, extend to multi-entity, or end the trial. We share what broke during the 30 days and what would change in a paid engagement.

    Deliverable: 4-page trial retrospective + extension proposal (if you want one). No proposal arrives uninvited.

Success metrics

Every metric below is computed from the structured log stream the product emits via logging.getLogger() — the same stream you forward to your SIEM. You can re-derive every number we report. No surveys, no hours-saved guesses.

  1. m1

    First-pass approval rate

    Source: draft.transition events where from=draft and to=approved with zero intervening to=rejected for the same bridge_item. Target on first close: ≥ 60%.

  2. m2

    Time-to-verdict

    Source: tool.execute.start for the first upstream sql_query → excel_write.complete for the approved output. We report median and range, not best-case.

  3. m3

    Bridge-item narrative accuracy

    Source: reviewer annotations on each bridge_item. Counts how many of YiG's narratives needed material edits before sign-off. High accuracy means the reviewer is verifying, not rewriting.

  4. m4

    Audit evidence completeness

    Source: count of audit_logger records per run, verified against the run's expected event shape. Either every action is in the log, or it isn't.

Commitments

Customer provides

  • Read-only access to two source systems (SQL view, file share, or warehouse credentials).
  • One reviewer with sign-off authority — controller, FP&A lead, or accounting manager.
  • Two close folder paths: approved-output destination + audit-log forwarding target.
  • ~3 hours/week of reviewer time across W2–W4.
  • One IT/security contact for the deployment-mode decision and BYOK key handoff.

YiG provides

  • One engineer attached for 30 days — on the integration call, the weekly check-in, and the production close.
  • The deployment (local install / VPC / managed) and the source-registration scripts.
  • The reconciliation tool (finance_basis_reconcile) and narrative-prompt tuning for your bridge categories.
  • The audit-log forwarding configuration for your SIEM endpoint.
  • The trial retrospective at week 4 — honest about what worked and what didn't.
version 1.1 every action logged

Apply for a trial cohort

Cohorts are small. The form takes two minutes.

We respond in 5–10 days with either a trial match or an honest "not yet, here's why." No marketing list.

Apply for the trial → Read the docs