Integrations
nCino integration for financial spreading
How a spread finished in SpreadSpace reaches nCino: an export map in nCino’s account codes, file and API handoffs on finalize, and an embedded workspace.
nCino is a cloud banking platform built on Salesforce, and its commercial lending workflow carries a loan from application through credit approval, closing and booking. Its own spreading and credit analysis modules sit inside that workflow. A lender that reviews borrowers in SpreadSpace needs the finished spread, its source documents and the analyst’s adjustments back on the nCino loan, under the account names nCino’s templates expect.
This guide describes that handoff as it works today. SpreadSpace names every account in nCino’s terms through a per-workspace export map, hands the finished spread over as a file, through the API when the analyst finalizes, or inside an embedded workspace, and nCino receives it through the integration paths nCino documents. No nCino-built connector exists, and none of the three routes needs one.
Where a spread lands in nCino
nCino’s commercial banking suite runs on the Salesforce platform, so a loan in nCino is a Salesforce record with related records for the borrower, the collateral and the credit analysis. nCino’s automated spreading feeds its Spreads tool, which nCino integrates into the commercial loan origination workflow with ratios, templates and trend analysis. A spread finished elsewhere lands in the same place: the financial statement records on the relationship that nCino’s credit memo and covenant tracking read.
That is why the account names matter more than the file format. nCino’s templates expect nCino’s line names, and a figure posted under the wrong line is a figure the memo misstates. The export map below gives every SpreadSpace account its nCino name before anything moves, and the payload carries both names on every line.
What SpreadSpace hands to nCino
Four things leave SpreadSpace. The first is the extracted document: every line a tax return, financial statement or bank statement prints, each with the page and the boxed region it was read from. The second is the mapped statement: the profit and loss statement and the balance sheet placed on the workspace’s chart of accounts, with each account’s figure per period and the arithmetic that walks the printed lines to the printed totals. The third is the finalized spread: the attribute snapshot an analyst approved, with its figures, periods and source document references, frozen at a version number. The fourth is the credit memo as a PDF.
Each has a file form and an API form. One document exports as CSV or JSON on its own, and a set of documents on one loan bundles in the background as CSV, JSON or, for bank statements, XLSX. The loan’s spread comes out as two Excel workbooks, one of statements and one of tables, with the rows a figure is derived from indented under it. The finalized figures are read from the loan’s attributes endpoint and the mapped statements from the borrower’s mapping endpoints. nCino receives whichever form its import takes.
Exports in the API documentation
Name every account in nCino’s terms
The chart of accounts is the workspace’s own. Its accounts carry SpreadSpace ids such as pl.opex.rent and bs.current_assets.cash, and nCino holds the same accounts under its own codes and names. The export map is the translation. In Settings, open Chart of accounts and then Export map, choose nCino as the system, and give each account the code and the name nCino uses for it. The map is saved once per workspace and applies to every loan, and the system is recorded as ncino on everything it codes.
| SpreadSpace account | Account id | Code and name in nCino |
|---|---|---|
| Revenue | pl.revenue.sales | 4000 Sales |
| Officer compensation | pl.opex.officer | 6010 Officer salaries |
| Rent | pl.opex.rent | 6100 Rent expense |
| Depreciation | pl.opex.depreciation | 6900 Depreciation |
| Cash | bs.current_assets.cash | 1000 Cash and equivalents |
| Accounts receivable | bs.current_assets.accounts_receivable | 1100 Accounts receivable |
| Current portion of long-term debt | bs.current_liabilities.current_portion_ltd | 2400 Current portion LTD |
From then on every mapped statement carries the codes. Each account in the mapping’s tree answers with its external code and label beside its figure per period, the payload names the system, and the accounts the map codes that the statement does not use are listed, so nothing posts blind. A map can also be saved through the API, up to 1,000 entries and the whole map each time, and a save that crosses another is refused rather than merged. After any save, each mapping reads as stale until it has been prepared again with the new codes, and a webhook announces the fresh one.
Statement mapping and the export map in the API documentation
Three routes into nCino
The first route is a file. An analyst downloads a document’s export or a bundle from the document list, a job requests the two workbooks, and the files are loaded through nCino’s import or attached to the loan. It needs no engineering and suits a team that files a few spreads a day.
The second route is the API. When an analyst finalizes a spread, SpreadSpace sends a spread.finalized event to your endpoint, signed with a shared secret, naming the loan and the snapshot. Your service reads the snapshot from the loan’s attributes endpoint and the mapped statements from the borrower’s mapping endpoints, with nCino’s codes already on every account, and posts them into nCino through the path nCino documents. SDKs for TypeScript, Python and C# wrap the calls, and the event carries the snapshot id, so a handler that records the ids it has posted stays idempotent under a retry.
The third route is the embedded workspace. Your application asks SpreadSpace for a single-use signed URL and seats the spread in an iframe beside the nCino record, so an analyst opens the source documents without leaving the loan, and no token crosses the parent frame. The figures still finalize into the same snapshot and reach nCino by either route above.
Webhooks in the API documentation
nCino’s side of the handoff
Because nCino is a Salesforce application, a lender’s integration team reaches it the way it reaches any Salesforce org: through the Salesforce platform APIs, through the middleware many institutions already run between nCino and the core, or through a data load. nCino packages its own integration tooling for its customers, so the object names for financial statements and the permission to write them come from nCino’s documentation and the institution’s nCino administrator.
The API route therefore ends in a mapping the lender’s team owns: the snapshot’s figures and the mapped statements, with nCino’s codes on each account, posted to the financial statement and spread records in the org when the finalize event arrives. The file route needs no object mapping. The statements workbook attaches to the nCino loan as a document, and the figures the nCino template needs are entered from a sheet that already carries nCino’s code beside each line.
Set up the handoff
Create an API key with the scopes the route needs: extractions read and export for the files and the mapped statements, spreads read for the snapshot, chart of accounts write to save the map from code, webhooks write to register the endpoint and embed write for the iframe. Save the export map for nCino. Register the webhook endpoint, send the test event and verify its signature. Then run the whole loop on a test key against the sandbox loan, whose sample spread finalizes on request, before the first live loan.
SpreadSpace ships no connector written by nCino, and no step above depends on one. The file, the API payload and the embedded frame are SpreadSpace’s side of the handoff. nCino’s side is its documented import, its API or its services team, and the section above names the public pages that describe it. A lender that wants the two sides joined for it can ask sales.
API keys and scopes in the documentation
Sample documents and the sandbox loan in the documentation
Integrating financial spreading with a loan origination system