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, or a Microsoft Project .mpp. 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.

Your browser does the reading. Nothing about a dropped file leaves it on its own: only when you ask the assistant to read a sheet PadFlow could not place do that sheet's values go to a model, never its formulas and never a sheet that was already understood. Every call carries an instruction to the provider that it may not keep or train on what it was sent.

A scan, or a photo of a printed sheet

A printed page has no rows in it. It never did: a scanned lot availability sheet is a picture of a table, and there is nothing in the file to read into a row. That used to be the end of it, and the only thing on offer was filing the page into the project's documents.

Drop one now and PadFlow shows you its pages, drawn in your browser. Pick the ones you want read and press Read these pages with the assistant. Images of exactly those pages go to an AI model, which transcribes what is printed; the tables it finds come back as sheets and go through the same reading, the same classification and the same review as a dropped workbook's tabs. Nothing is written until you confirm, exactly as before.

What it takes: a scanned PDF, or a .png, .jpg, .webp or .tiff. An Apple .heic photo is refused by name, because most browsers cannot open one; export it as a JPEG first. A picture is judged by its contents, not its name: a file whose bytes are not a PNG, JPEG, WebP or TIFF, such as an HEIC or AVIF renamed to .jpg, is not opened, and the page is listed as not read with a sentence saying what it was. The same rule holds for a photo that arrives by email.

Three things are worth knowing before you press it:

• Only the pages you pick go. Not the file, not the pages beside them, and not a page you tick afterwards. The button names the pages, and the sentence above it says what leaves and what it draws on the workspace's daily reading budget.
• Ten pages go in one read. A longer document is read a batch at a time.
• A figure the reader was unsure of is a question, not an amount. A transcription is characters somebody's reader chose, so every cell carries how sure it was, and a doubtful one lands in Needs you with the page's reading on the card rather than in a budget. That is the whole difference between reading a scan and trusting one.

Some pages come back unread and say so: a page with nothing printed on it, a page scanned as black-and-white fax, a page over the size a read carries. They are listed by number. Nothing is invented for them.

Filing the page into documents is still there, on the same card. The two are different choices and neither implies the other. Whichever you choose, the card says what came of it: a filed document says what was read out of it and how many proposals are waiting on it, and if the reading could not be saved it says so and offers Read it again, which reads the file the library already holds rather than uploading or filing a second copy.

Reading a scan: what you pick, what leaves, what you see, what lands

A scanned page is the one thing on this screen a model transcribes rather than a reader parses, so the review is built to be checked rather than believed. Four steps, and each one is visible while it happens.

What you pick. Every page of the file is drawn in your browser and every one that carries a picture is ticked, up to one read's worth. Untick what you do not want read. Nothing has left your browser at this point and nothing has been called.

What leaves. Images of exactly the pages on the button, and nothing else. The sentence above it names them, says where they go, says the provider is told it may not keep them or train on them, and says what the read draws on the workspace's reading budget for today.

What you see while it reads. The pages found, the pages you consented to, each page as it is drawn and each page as it comes back, with what came off it: tables, facts, and any region the reader itself said it could not make out. It counts pages ("page 2 of 5") and never shows a percentage, because how long the remaining three will take is not something PadFlow knows. A page that produced nothing is named with the reason rather than quietly missing from a total.

What you see in the review. Every proposed row that came off a page carries a pn beside it. Open it and you get the part of the page that row was read off, the characters the reader chose, what you corrected them to if you did, and three separate statements about being sure:

• read: how sure the reader was of those characters. The only one of the three that is a number, because it is the only one anything measured.
• kind: what the sheet was recognised as, and how. A rule that fired, a tie a filename broke, the assistant's reading, or your own answer.
• place: where the row lands. New, over a row already here, or in disagreement with one.

They are never folded into one figure. A row can be transcribed perfectly off a sheet that was recognised wrongly, and a badly transcribed row can land somewhere nobody doubts; an average of the three would be right about nothing.

What lands. Directly above Confirm is a strip with three counts: proposed, excluded and unresolved. Proposed is exactly what the button writes and the button carries the same number. Excluded is what will not be written and why: rows already on the project, rows that disagree with one, sheets you left out. Unresolved is what nothing has an answer for yet, and every one of them is named: this page of that file, this row of that sheet. A page you never ticked is on that list, and no row from it lands.

Where several sheets came back with a reading waiting on you, Accept all n listed accepts exactly the ones on the list and says how many. Each is still shown with what it was read as and why, and accepting writes nothing: Confirm is still the only thing that writes.

Afterwards the receipt says what the database did: how many rows it accepted, how many of those were written over a row already here, and how many it kept as they were because somebody edited them while you were reading. If the run was confirmed with anything unresolved, the receipt names it there too, so a week later you can see where the rest of the file went. Where the reading came from a document on the register, the receipt links it.

A scan that arrives by email

A scan emailed to a project's intake address is filed on the register like anything else, and by default it stops there with Open in import on its row. Reading it means sending a picture of every page to a model, and nobody was at a keyboard to say so. A workspace can say so once instead: Reading emailed scans and photos, under Automation, off until an admin turns it on.

With it on, the pages are read when the file lands and the run that has been prepared is the same review a drop produces: the tables come through as sheets, and what the pages say about the document (a face amount, a party, an expiry) comes through as lines with Accept and Skip on each. Nothing reaches a project until somebody confirms it. The pages that were not read are named on the run, and the sender's receipt says what kind of document it was read as and how many lines are waiting, and nothing else about it.

Reading is charged once per document. A retry, a forward and the same file dropped by hand afterwards join the reading that already happened, and opening that document in import opens the reading rather than offering to pay for a second one.

A Microsoft Project schedule

Drop the .mpp itself. There is no need to export an XLSX from Project first.

What comes over is the plan: every task, the phases it sits under, its planned start, and what it follows. A predecessor becomes a rule pointing at the task it depends on, so moving that task moves this one. That is the whole reason for importing a dependency rather than a date. Summary tasks become the group on the tasks beneath them rather than duplicate rows beside them, a milestone comes over as the task it already is, and a task Project records as finished comes over as finished on the date it finished.

What does not come over is said out loud on the review, never left out quietly: resource assignments and costs, a link type a task record cannot hold, a task that is part-way done (a task is done or not done, so a 40% task imports as not yet done and the review says so), and a predecessor that is not in the file. Every row in the file is imported, folded into a phase, or refused with a reason.

This is the one file PadFlow does not read in your browser. The .mpp format has no browser reader, so the file is converted on our server and only the schedule comes back; it is not filed and it is not stored. A deployment without the converter installed says Microsoft Project import is not available on this deployment rather than failing in some other way.

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.

This drop zone is the only import that writes draws. A project's own date and amount merge never writes draw history, funded or otherwise, which is why a ledger is dropped here rather than there.

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.

Because an imported draw lands funded, with every line approved, importing a ledger is a funding decision rather than a budget one, and it asks for exactly what funding a draw by hand asks for: approval rights on money, and your own approval limit against each draw in the file. One draw over your limit refuses the run and names it, rather than landing the rest. An accountant who may write a budget can drop the same workbook, land the budget half, and be told plainly about the ledger.

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.

A row somebody changed while you were reading

The review screen shows what a merge would write over. If somebody edits one of those rows between the review opening and you pressing Confirm, that row is left exactly as they left it rather than written over, and the receipt says how many were kept and why. Everything else in the run lands. This is why a review left open over lunch is safe to confirm: the answer can only be narrower than the one on the screen, never wider.

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, PDF, Microsoft Project file or photograph of a page 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.

Files PadFlow has already read

A workbook, CSV, text PDF or Microsoft Project file that arrives at a project's intake address is read when it lands, and the review is waiting for you: the bell in the header counts it beside the documents PadFlow filed, and following it opens the reading it already did. The review says so at the top, in as many words: PadFlow read this file when it arrived. Nothing is imported until you confirm. Under that sentence it is the ordinary review, with the same rows, the same conflicts and the same Confirm.

Nothing is written by the reading. Confirming it is what writes, and Dismiss this reading is how you say no; either way the file stays filed on the register. The same file arriving twice, as a reply or a forward or a digest, joins the reading it already has rather than preparing a second one, and a changed file is a new one. A file that could not be read is a run too, saying why, so nothing arrives silently.

A photograph is not read on arrival, however it got here. Reading a page costs a model call and sends an image of the document, and neither is a thing to do because an email arrived: the photo is filed on the register, its row carries Open in import, and the page picker there asks before anything goes.

Reading email is a workspace switch, on to begin with, under Automation in settings, with the most readings a day that may reach a model beside it. Off, an emailed file is filed and waits, exactly as it did before, and Open in import still works.

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 draw with invoices assigned to it or a line somebody has approved since, a task another task is now anchored to, and a cost code or a party anything else in the workspace now refers to.

Undo asks for the access the run itself asked for, one class at a time: taking back a budget needs money, taking back a schedule needs the schedule, and taking back funded history is a reversal, so it needs approval rights and your limit against each draw, which is what unfunding a draw by hand asks for.

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; a budget needs money; a draw ledger needs approval rights on money, because it lands funded; 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.