Bring a running deal in

Every import across the workspace, and the drop zone that starts one: schedule, budget, takedowns and the draws the lender has already funded.

Most deals do not start in PadFlow. They start in a folder: a tracker, a budget exhibit, a takedown table, a term sheet, and a ledger of the draws the lender has already funded. This page is how all of that arrives.

The four files, and the fifth

A deal that is already running brings four documents, and a fifth once there is a loan:

• The schedule. A tracker with the plan formulas in it. The rules come over as rules, not as typed dates, so the cascade works from the first day.
• The dates. A list of what falls due, and what each one follows.
• The budget. A lender exhibit of budget lines, an internal sheet of cost codes, or both.
• The takedowns. A numbered release with a quantity and a date.
• The draw ledger, where a loan has closed and money has already moved.

Drop them all at once. Nothing is asked about what a file is: each sheet is read from its own columns. The one question is which project the files belong to, because that is the one thing no spreadsheet can be read to discover. The project is created first; a budget exhibit does not carry a deal's name.

Draw history

A lender's ledger of draw number, date and amounts imports as funded history. It never lands as a proposal, and it never sets off the draw approval flow or its notifications: the money moved before PadFlow was here, and recording it is a filing job, not a request.

Each row is matched to a budget line by its label, the same way a budget merge matches one. An amount against a line the budget does not have is a question, never a line invented to hold it. Two sums are checked before anything is written: a draw has to equal its own lines, and a line can never be drawn past its budget. A sheet that disagrees with itself is refused with both figures on the screen.

Loan terms

A term sheet or a loan agreement is a different shape: one record, not a table. PadFlow reads the fields the loan form asks for, and then stops. Nothing about a loan is ever written by an import. Each field is shown beside the line it was read from and beside what the loan says today, and you tick the ones that are right.

Parties

A list of names, roles and contacts imports into the party register. A name the register already answers to, as a legal name or as any alias against it, is a suggestion that the two are the same party rather than a second row. One company owed two balances is the thing this is protecting against.

Files that are already here

A spreadsheet that arrived by email is already on the documents register. It does not have to be found again on somebody's machine: any filed or queued workbook, CSV or text PDF carries an Open in import action, on the register and in the intake panel, which starts a run on that project with the stored file. One pipeline for arrival, one for extraction, and one action joining them.

The registry

Every run in the workspace is listed here, newest first: when it ran, who ran it, which files it read, what landed where, and whether it still stands. Each row opens its project's own review, which is where the detail lives.

Undo takes a whole run back. It restores what the run overwrote, and it skips and names anything it cannot honestly touch: a row somebody has edited since, a lender line with draws against it, a cost code with invoices posted to it, a draw with invoices assigned to it, a party something else now refers to.

Who can open it

Importing writes rows, so it needs the schedule, money or documents at edit, and each destination is checked again on its own when you confirm: tasks, dates and takedowns need the schedule; budgets and draw history need money; the party register needs documents or money. Someone who can import a schedule and not a budget can drop a workbook holding both, land the schedule half, and be told plainly about the other.