The transaction record and extracted data

The Overview tab brings the transaction's facts together in one place; each value links to the page it was read from, and the signed documents govern if anything differs. Its centerpiece, the Transaction Record card, holds the facts LetterScript extracted from your documents — the full transaction sheet a coordinator would otherwise build by hand: address, APN, sale price, list price, the deposit structure (earnest money, increased deposit, seller credits), financing type, buyer's broker compensation, who pays which closing costs (escrow fee, title policy, transfer taxes, the Natural Hazard Disclosure report, home warranty), escrow holder and file number, HOA and occupancy status, key dates, and highlights.

It fills itself in

You don't type these fields. A brand-new transaction shows a single prompt in their place — click Upload documents right there to add the first files. As each uploaded document finishes Analyzing, its facts merge into the record:

• The purchase agreement anchors most of it — price, parties, contingency periods, cost allocations.
• Counter offers supersede the original terms they amend; the record always reflects the finally-agreed numbers and dates. A counter that was only proposed (signed by one side, or accepted subject to a further counter that isn't uploaded or wasn't accepted) doesn't override the agreed terms. Once that further counter is accepted, the earlier counter's terms it didn't change still apply, as the forms say. While nothing but proposals is on file, including a purchase agreement the seller signed only subject to a counter offer, the transaction isn't shown as In contract. An addendum or amendment on its own doesn't make it In contract either: it amends a purchase agreement that isn't on file, so upload that agreement. Both rules need the whole file: while a document on the transaction couldn't be identified (its row on the Files tab reads Set type; an email's own text and an unpacked ZIP file don't count) or failed to process, any purchase agreement, counter offer or addendum on file is enough to show In contract, because that document may be the one that accepted it. A counter's acceptance date is the date the other side accepted it, not the date it was offered. A seller multiple counter offer (SMCO) is different: the buyer's acceptance in its paragraph 7 doesn't bind it. It binds when the seller signs the paragraph 8 selection (8A) after the buyer, so until the 8A signature lines carry a date it counts as a proposal, and once they do, its acceptance date is the seller's 8A date, or the buyer's late acceptance in its paragraph 9 when that is signed after it. A selection in back-up position (8B) doesn't make it the contract. A counter offer or an amendment of existing agreement terms (AEA) accepted after its own expiration date, with no late acceptance signed by the side that made it, is treated as a proposal: the forms say a late acceptance binds only once its maker agrees in writing, and the AEA prints no way to ratify one at all. Under the C.A.R. forms, acceptance happens when the signed acceptance is delivered to the other side or their agent, which can be later than the date LetterScript reads (the agreement's Confirmation of Acceptance date, or the seller's signature date when that line is blank); if it was, correct the acceptance date by hand.
• A repair response is agreed only once both sides agree to the same terms. A buyer reply that accepts the seller's response with a modification binds only once the seller ticks Seller Agreement below it and signs; until then, or once the seller ticks Seller Rejection, nothing is agreed. A reply that withdraws the request isn't an agreement either. In each case the seller's offered credit or revised price doesn't reach the record.
• Repair credits add up instead. A credit the seller agrees in a repair response doesn't replace the transaction's other credits — the Request for Repair says so in print — so the seller can owe a counter offer's closing-cost credit and each agreed repair credit. The record keeps one figure, the latest; its explanation lists the credits owed on top of it, and a finding on the Overview adds them up for you to confirm before the closing statement is drawn. The same finding flags a closing statement that applies a different figure than an agreed repair credit. Two uploads of one repair response count as one credit, and the finding names the copy it set aside.
• A rejected offer never sets the terms. A purchase agreement whose Offer Not Accepted block the seller initialled is a rejected offer, so in a folder holding several offers it doesn't supply the buyer, price or dates over the accepted contract, even when it's the fullest copy. Of several copies of the contract, the one both sides signed is the one used.
• The price on the transaction's board card follows the record as it changes, so an amendment that changes the price changes the card too, and so does a correction you make on the record. It doesn't step back while the document that set it can't be identified, is still being read or re-run, or failed to process. If the accepted counter offer can't be identified, for example, the record falls back to the purchase agreement's price, but the card keeps the counter's price until that document has been identified and read again, or a document that supersedes it, such as a later amendment or the settlement statement, states a price. A correction moves the card at once: if you pick another type for a document misread as a counter offer, or it's read again as only a proposal or with no price, the card follows the record. If the record loses the agreed price altogether, the card keeps it instead of showing the list price, until an agreed price is read again. A price typed onto the transaction directly stays as it was entered. On a deal imported from Follow Up Boss the card shows Follow Up Boss's price, which follows Follow Up Boss until someone changes the price here (see Follow Up Boss deals below).
• The file is cross-checked as it fills in. You see a finding when a counter was accepted subject to a further counter that isn't uploaded, when a counter's own wording ("the $10,000 increase in purchase price") disagrees with the price it sets, when the seller accepted after the purchase agreement's written Expiration of Offer date, or when a counter offer or amendment was accepted after its own expiration date with no late acceptance signed by the side that made it.
• Later documents enrich and cross-check what's already there. The more of the file you upload, the firmer the record gets.
• A document that's still being identified, read or re-run doesn't empty the record. Until it's read, the record keeps the values it supplied, while the documents already read keep updating the rest — including a counter offer or settlement statement that changes one of those values. The exception is a re-run of the transaction's only document: the record can be emptied while it runs, and it's filled in again once the document has been read. If LetterScript can't identify a document, it's filed with no type and its row on the Files tab reads Set type, so you can pick the type yourself; it counts toward the record once it has been read.
• On a transaction that has reached its AI processing limit, LetterScript can't identify or read any more of its documents until the limit is lifted (on a free first transaction, buying a transaction lifts it). Nothing new is read from them, but the record keeps the values they already supplied, as above, and the transaction's status follows the documents already read. While such a document is waiting to be identified or read, a purchase agreement, counter offer or addendum on file is enough to show the transaction In contract, even one that's only a proposal or that the seller signed subject to a counter offer: the document LetterScript can't read may be the one that accepted it.

Follow Up Boss deals

On a transaction imported from Follow Up Boss, its name, price and stage come from the Follow Up Boss deal and keep following it: when the deal changes in Follow Up Boss, the transaction changes too, and the change is recorded in your Audit log (Settings → Audit log) as Follow Up Boss sync, not as anyone's edit. The Overview says which values those are, marked From Follow Up Boss.

Once you change one of them here (rename the transaction, pick another stage, or correct the sale price on the record), yours is kept: Follow Up Boss no longer overwrites it. The Overview shows what Follow Up Boss says instead, for example "Follow Up Boss says the stage is In Contract", with Use Follow Up Boss's to take its value; once the two match again, the value follows Follow Up Boss again. When Follow Up Boss changes a value you've kept, the Audit log records that yours was kept.

A value that changed here some other way is kept the same way, but isn't called yours: if the Follow Up Boss deal had no price when you imported it and the documents filled one in, a price later typed into Follow Up Boss doesn't replace the contract's, and the Overview says "The price here is kept". Renaming a stage in Settings doesn't count as a change: the transaction keeps following its Follow Up Boss deal under the new name. If you disconnect Follow Up Boss, the Overview stops saying which values follow it, since nothing syncs any more. People you share the transaction with from another workspace don't see what your Follow Up Boss deal says.

Every value traces back to a document

No fact in the record is just asserted — each one remembers where it was read. Values that carry a source are underlined; click one to see it in context.

• Most values open the document at the exact spot, with the value highlighted on the page.
• Some values open the document alongside the assistant instead — the document on the left, the assistant on the right — with the question already written for you. Press Enter to run it, or reword it first.

The second case is deliberate, and worth understanding. Some facts are a conclusion rather than a phrase the document prints. A purchase agreement saying "the Property is within the Stonelake Master Association" establishes that there's an HOA — but the word "yes" appears nowhere on the page, so there's nothing honest to highlight. Rather than drop you at the top of a 20-page contract to hunt for it, LetterScript puts the document and the assistant side by side and hands it the question. The assistant has to ground its answer in the text, so the reply comes back with citations — and clicking one scrolls the document beside it straight to the passage it quoted. You end up looking at the wording that backs the value, which is what the highlight would have shown you if we'd been able to find it.

The same happens for who pays which cost (the answer is a checked box, not the words "Buyer" or "Seller"), occupancy, sale type, and for anything we couldn't pin down — a scanned page with no searchable text, for instance.

A value a person set carries a badge instead of a source link, and the same two words are used everywhere in the app — the record card, the Parties roster, the milestones editor, the disclosure checklist:

• Edited — someone changed a value the engine had produced. Hovering it names who and when ("Edited by Dana Reyes · Aug 27"), and the small revert arrow beside it puts the document's value back.
• Added — someone created a value the engine never had. There's nothing to revert to, so instead of the arrow there's an × that removes the value. On the Parties roster, a person the documents found is never Added: filling in a phone or email the documents left blank still reads Edited, because the person and the rest of their details came from the documents.
• Confirmed — someone kept the value the documents already state, for example by clicking Use on the reading the record already had. The value still links to the page that states it, and the assistant still cites that page. Like an edit, it stays put if a later document changes the value: the docs changed marker appears beside it, and clicking that uses the documents' new value. Until then it's treated as that person's value, not the documents': it no longer links to the old page, and the assistant (and any AI assistant you've connected) says a person set it rather than citing the documents.

In the milestones editor, a date someone marked done, or N/A, carries that person's first name beside the chip instead (the start of their email address if they haven't set a name), and hovering it says when, and whether the documents show it done too. A cure date someone marked done that the calendar has since moved on from, to the next notice to perform, is listed under the dates as Notices to perform settled by hand, with that person's name and a Reopen. See Marking a date done in Deadlines and the timeline.

Attribution matters the moment a transaction is shared: the badge names the person, and says "you" only when it was you. Beside a corrected value on the record card, the words say who corrected it ("you corrected this", "Dana corrected this"), and the card's header counts the corrections and says whose they are, or edited by hand when they're several people's. The same goes for a party someone corrected on the Parties roster, a deadline, a requirement on the Files tab and a step on the purchase timeline. On the Parties roster, where hand-set and extracted rows sit side by side, extracted ones carry the counterpart From documents badge, so an unmarked row never has to carry meaning on its own.

The LetterScript mobile app shows the same thing, read-only. On a transaction's Overview, a corrected value shows the corrected value and says Edited by (or Confirmed by, or Cleared by when someone emptied it) with who and when and any note, and if the documents have changed it since, what they say now; correct it, or put the documents' value back, on the web. A person's party says who added or edited it, a date set by hand says who set it (the close of escrow under Key dates too), a document type picked by hand says who set it, and a state set by hand shows a pin with who set it. The note under the Overview that says its values were read by AI says these values weren't.

The transaction's state

The pill beside the transaction's name shows its state (In contract, At risk, Pending close, Closed, Cancelled and so on), which follows the documents: a cancellation or a notice to perform moves it. A cancellation of contract (CC) that one side makes on its own (paragraph 1A) cancels on that side's signature, even with the form's page 2 left blank; a proposed mutual cancellation (paragraph 1B) cancels only once both sides have signed. On a short sale, a lender-consent form (DSSC) whose paragraph 2 is checked and signed by the party cancelling cancels the transaction too. The seller's notice at the bottom of page 2 of a home-sale contingency (COP) puts the transaction At risk, like a notice to perform (see Deadlines and the timeline). A contingency removal, notice, demand to close or withdrawal whose signature lines were read and left unsigned doesn't move the state. On a default-sale contract (NODPA), LetterScript treats the owner's notice of cancellation as cancelling only once the owner has signed it: the unsigned copy that has to go with the contract doesn't, and one whose signature line couldn't be read doesn't either. Legally, the cancellation takes effect when the owner's written notice is delivered to the address in the contract, and any writing that shows the owner won't be bound will do (Civil Code §1695.4), so if the owner did cancel, set the state from the pill. Choosing a state from the pill sets it by hand instead, and pins it: documents uploaded later don't change it until you choose Auto (clear override) from the same pill. A pinned state shows a pin icon on the pill, and on the transaction's card on the board; hovering it says who set it, when, and any note they left. Choosing the state the pill already shows doesn't pin it, so a stray click never freezes the state; a message says so instead. To keep the state the documents show and stop documents added later from changing it, choose Keep state from the same menu. If the state changed while you had the page open, the state you choose is the one that's set, even when it's the state the transaction has since moved to. The Timeline tab's status banner says the same.

It follows the data across the tabs

The same click-through sits on the Overview's Parties and Milestones sections, and on the People tab. Because those rows are editable fields rather than plain text, the citation is a small document icon at the end of the row — click it for the same two outcomes: the page with the value highlighted, or the document opened side by side with the assistant.

A person shows the same citation whether you look at them in the Overview's Parties list or on the People tab — it's the same answer to the same question, so it doesn't change with the view.

The Workflow tab traces back a little differently, because its rows aren't values read off a page — they're things documents did. See Deadlines and the timeline.

A row shows the icon only when we can point at something honestly:

• Parties — the roles the record resolves as a fact of the transaction (buyer, seller, owner of record, lender, escrow holder, title company, tenant), and only when the cited wording actually names that person. Agents and transaction coordinators aren't record fields, so they carry no icon. Neither does an escrow officer whose name doesn't appear in the escrow company's citation — pointing you at the wrong line would be worse than pointing nowhere.
• Milestones — the ✨ auto-derived dates. Dates you typed yourself have no document behind them, and neither does a date whose underlying record field you corrected: the icon goes away entirely rather than falling back to "somewhere in this document". The deadline now follows your value, so pointing at the page you corrected it away from would be worse than pointing nowhere — and for the same reason, that correction is no longer what ⌘K or the assistant's scope deep-links to.

Parties become contacts

The people on the documents become the transaction's Parties automatically — buyers, sellers, both agents (with brokerage and license number), transaction coordinators, the escrow officer, the loan officer — each with whatever phone and email the paperwork (and, for trusted senders, transaction email) states. The brokerage firm on each side is listed once, as the Listing Broker or Buyer's Broker, with the firm's own license number as the purchase agreement prints it — not as a second agent. A company that's only someone's employer, like the escrow company beside its escrow officer, isn't listed again as if it were another person, and a line that names people together ("Priya Nakano and Victor Nakano, Trustees of …") becomes those two people. An escrow officer isn't given a license number of their own: the one a purchase agreement prints for escrow belongs to the escrow company, so it goes on the escrow company's entry — and when the paperwork names the company only beside its officer, the company gets an entry of its own to hold it. When a trust sells, the record's Seller is the trust: a purchase agreement often names only the trustees, and when this sale's listing agreement or title report names the trust and a document on file ties each trustee to it by full name (as its trustee, or as a signer of that listing agreement or report), the record shows the trust and its explanation says how the trustees were tied to it. A trust that only shares the sellers' last name doesn't count, nor does a listing for another property or one that ended before the contract, and when a settlement statement or deed names the people themselves as the seller, they stay the seller. The trustees stay on the party list as the people who sign. Extraction only ever fills blanks: a party you typed or edited yourself is never renamed or overwritten, and details found later just complete the card. A detail LetterScript can't vouch for (say, a phone number that turns up on a different document than the one naming the person) isn't added to a party whose email or phone you entered yourself. On a party you added without any, it's added and the party is marked Unconfirmed until you look: changing that detail, or the party's email or phone, clears the mark. People a Follow Up Boss deal brings in, whether with Import from FUB or a later sync, are marked From Follow Up Boss instead of From documents, until a document names them too; from then on they're marked From documents. Follow Up Boss doesn't say what part someone plays in the deal, so they get no role until a document names one: once the purchase agreement names them as the buyer, for example, they're listed as the Buyer, and later syncs leave that alone. Remove someone with the × beside them and they stay removed, even though the documents (or Follow Up Boss) still name them: later uploads and syncs leave them off, including when the documents spell the same name a little differently — with or without a middle initial or a "Jr.", last name first, or a misspelled last name at the same email address. Anyone who only shares their email address, like a spouse on a family email or a colleague on an office one, isn't affected. They're listed under Removed parties, below the list, with who removed them and when; Restore puts them back as they were, and adding them again by hand lifts the removal too. These contacts are what the email composer's suggestions, recipient groups, and the letters on the Send menu all draw from. An email address read off a document doesn't make that person a trusted sender, though: mail from it waits for your OK until you trust it (see Email from inside a transaction). Before a letter or sheet goes out, its review screen lets you correct a contact for that copy only, or fix it here in the record (see Send and share from a transaction).

Each correction on the Parties roster saves on its own and changes only the field you edited: a phone or email the documents fill in for someone else while you work is kept, and nobody else's row is marked Edited by your save. If a value changes while you have it open, the row says what it is now — saving replaces it with yours, and cancelling keeps it. Undo, right after you remove someone, puts them back exactly as they were, without touching anyone added or changed in the meantime. If someone else removed a person while you had the page open, your change to them isn't saved: they're listed under Removed parties, where Restore puts them back. Someone you add who the documents name at the same moment is added once, with what you typed.

The N people to confirm item in the transaction's Needs you band counts people. The Listing Broker and Buyer's Broker rows and an escrow company's own row are firms, so they aren't counted; they're still on the People tab, where you can confirm them.

People cards are shared across transactions

Each party also gets a card in your People directory, and that card is shared by every transaction the person is on. A card made for someone the documents name is marked Auto-generated, and one made for someone from Follow Up Boss is marked From Follow Up Boss; both wait for you to Verify them. Once someone corrects such a card, it says Edited by with who and when instead, and still waits for Verify: correcting one detail doesn't vouch for the rest of the card. Hover the check mark on a verified card to see who verified it and when; a card someone added by hand says who added it. People you share a transaction with from another workspace see that a card was edited and when, but not by whom. Only people you add yourself start out verified. Two mentions land on the same card only when nothing says they're different people: the same email address, or the same name with no conflicting email, license number, or company. Two escrow officers who share a name but work for different companies get a card each. When a repeated entry like the ones above — a company beside its own officer, or a line naming two people together — is folded out of a transaction's party list, the card it had already made in People goes with it, unless you've verified that card, added notes to it, assigned a task to it, booked a meeting with it, or it's on another transaction. Each card removed this way is recorded in your Audit log (Settings → Audit log), against that transaction.

On a transaction's People tab, each person's email, phone, and company are the ones this transaction's documents give. A detail this transaction doesn't have stays blank there, even when their card has it from another transaction — so the tab and the email composer's suggestions stick to what this transaction says. Edit opens the shared card itself, and a change you save there reaches their other transactions too. That includes a transaction whose documents are being read at that moment: it ends up with your corrected details and tied to the card you corrected, and a copy of the card the reading made from the old details meanwhile is removed again, on the same terms as a folded entry above, and recorded in your Audit log the same way. Only the details you change are saved: a phone or email the documents add to the card while the dialog is open is kept, not cleared. Delete removes the card and also takes the person off the party list of every transaction they're on, so those transactions stop emailing them. Each of those transactions keeps them off when its documents are read again, lists them under Removed parties with Restore, and records the removal in its history in your name. Click a person's email address to write to them: on a transaction you own, when your plan includes email, it opens the transaction's composer, and anywhere else your own email app (see Email from inside a transaction). On a person marked Unconfirmed, it asks before going ahead.

A person marked Linked to the wrong contact is tied to a card that belongs to someone else with the same name — an older mix-up between two namesakes. The row still shows this transaction's own details, but editing, verifying, deleting, or scheduling on it would act on the other person, so those are switched off. Their email address still works, but asks first, since it may not be theirs. Click Separate on the row to give them a contact of their own; the other person's card and transactions are left as they are.

Auto-derived dates get flagged

Some deadlines aren't stated outright in a document — they're calculated from the contract (a contingency that runs a set number of days from acceptance, for example). LetterScript marks these so you can give them a second look:

• On the Workflow tab, an auto-derived deadline carries an amber date needs review note — worth a glance, especially right after a new counter offer lands.
• In the milestones editor, an auto-added date shows a small green sparkle icon; hover it to see what it was derived from (Auto-added · …).

Dates you set or confirm yourself carry no flag. See Deadlines and the timeline for how the dates are derived.

When the contract sets the close as a number of days after acceptance rather than a date, no page prints the closing date. The record's Close / recording row then shows the date from the transaction's milestones, marked computed, with how it was counted (or from the milestones when that date was set by hand). Possession does the same when it falls on the close. Neither links to a page, since no page states the date. The pencil still sets a date of your own.

When an addendum starts the contract's time periods on a later event than acceptance (a short sale, a back-up offer, a replacement-property contingency), the record says what the dates are waiting for under These deadlines have not started yet, or, when the start could have come sooner than the documents on file show, raises These deadlines may start earlier. Deadlines and the timeline explains each one.

When an extension of time states a contingency date but LetterScript can't tell which contingency it extends, the record raises Extended contingency not applied. No contingency date moved; check which box the extension ticks and set that date by hand. When an extension's new close of escrow reads as the day it was signed, and the form names nothing it extends, the record raises Extension's new close may be its signing date. Open the form: if it states no new date, the close should stay where it was. An extension whose item matches neither the close nor a contingency raises Extension applied to nothing, and nothing moved.

A few more flags name their own heading:

• Contingency period assumed from the printed default: the Review of Public Report period (ABSPA paragraph 3M(6)) couldn't be read, so the calendar uses the form's printed number of days. If the "(or ___)" blank is filled in, set the date by hand.
• Contingency stays open until close: the vacant land purchase agreement keeps the manufactured home purchase contingency (VLPA paragraph 3L(3)) in effect until close of escrow, so it has no removal date on the calendar. The buyer can cancel on it until close unless it's removed in writing.
• What a contingency removal keeps back is unclear: the removal's EXCEPT line names something LetterScript doesn't track. A contingency removal reads two ways: its blanket "all contingencies" box and its wording disagree. Either way, check what the form removes.
• Addendum read as a prior escrow's paperwork: a deferral addendum signed before this contract's offer existed no longer holds up the dates.
• Seller's close of escrow extension: a seller's contingency removal (CR-S) elects, in its paragraph 2A, to extend the close of escrow. When it was applied, confirm the replacement-property addendum's paragraph 2C allows it, since the form voids the extension otherwise; when it wasn't, the flag says why, and you can set the close by hand if the extension is valid.
• Contingency removal waiting on an agreed repair: a buyer's contingency removal attached to a request for repair (or the seller's response to one) is only valid once that repair is agreed, and no agreed response is on file, so its contingencies were left open. Upload the signed response if the repairs were agreed.
• Accepted counter or addendum may lack a signature: a counter offer or amendment reads as accepted and dated, so the calendar uses its date and terms, but its signature blocks read as missing one side's signature. Confirm both sides signed it: if they didn't, it has no effect, and the dates taken from it are wrong.
• Notice may have been delivered too early: a notice to buyer to perform was delivered more than 2 days before the deadline of a contingency it demands, or a demand to close escrow more than 3 days before the scheduled close. The purchase agreement makes it void for those items (RPA ¶14E, ¶14G), so it gives no right to cancel on them. Its cure date stays on the calendar; confirm the delivery date and the deadline, and if both are right, a new notice can be served once the window opens.
• Acceptance date not found: the contract's acceptance date couldn't be read, so no deadlines can be counted until you set it or upload a clearer signature page.

When a document contradicts itself

A conflict marker means two documents disagree, and you pick which one is right. A blue check source badge means something different: nothing is contradicting the document — the document is contradicting itself, or LetterScript's two readings of it disagree. There's no rival document to choose, so the badge explains what happened and offers the readings side by side. Hover it for the short version; the matching entry below the record spells it out in full.

Four things raise it:

• Pages that don't read alike. A scanned or flattened form can OCR one page differently from the rest — sixteen pages reading "5001 Cribari Vale" and one reading "5001 Cribart Vale". LetterScript takes the reading on the majority of pages and tells you which pages backed it, with the other reading listed beneath. It only does this when the majority is unambiguous; a genuine two-way split is left alone.
• An amount written two ways. A listing agreement states the list price in words and in figures. LetterScript reads the two separately from the C.A.R. listing agreement's price line, so they're never merged into a number neither of them states. When they don't match — "One Million Fifty-Two Thousand" written beside 928,000.00 — the record shows the figures, and the entry below lists both readings so you can confirm which one the seller agreed to. If the figures couldn't be found beside the words, the entry compares the words with the price read from the form instead.
• A percentage that can't be right. A signed PDF sometimes renders "3.000 %" into text that reads as "3,000 %". A buyer's broker compensation of 3,000% of the purchase price isn't a term any contract means, so it's read as 3% and flagged. The same goes for a percentage the deal summary turned into dollars: when a Compensation Agreement prints "2,500 %" and the summary says "$2,500", the record shows the 2.5% the document means, flagged, and the summary's highlight reads 2.5% with the printed "2,500 %" beside it. When the figure can't be explained that way, it's left exactly as extracted and flagged anyway.
• The record and the summary disagreeing. Two passes read your documents — one builds the Transaction Record, the other the plain-language deal summary. When they land on different answers for the same fact, you see it here instead of finding the two surfaces quietly saying different things. The summary wording a figure differently isn't a different answer: a $9,381.67 credit and the summary's "$9,381.67 at Close of Escrow, agreed in Seller Response No. 1" (or its older whole-dollar "$9,382") raise nothing, and neither does a total stated beside its own parts. A summary that names several amounts with no total among them still raises it, because it states no single figure to compare. Neither is an occupancy worded two ways ("Owner Occupied" and "owner-occupied"). Occupancy is who occupies the property at sale — owner, tenant or vacant — so the purchase agreement's Occupancy Type box (Primary, Secondary or Investment), which is how the buyer means to use the home, never fills it. When the record took a Sale type from the purchase agreement, the card says so: an agreement states the kind of sale only by writing it in, usually under Other Terms, so check there before you choose. Both readings keep Use this.

In the transaction's Needs you list each of these is named by its field — Occupancy: check source — so two on one transaction never read as the same row.

Every one of these is a prompt to look, not a verdict. Open the source document from the field's citation, then Use this to adopt a reading (on a money field it appears only when the reading is a single amount; a reading that lists several amounts says so, and you type the amount with the pencil), the pencil to type your own, or Accept as-is to dismiss the flag. Whatever you set by hand wins and carries the Edited marker from then on, or Confirmed when what you picked is the value the record already had.

The summary's Highlights and Key dates don't get a badge — they follow the record instead. A contingency deadline is shown as the timeline counts it, so a loan contingency filled in as 21 days reads 21, not the 17 the form prints. Where part of a highlight contradicts the record, that part is left out rather than shown beside the value it disputes, and the rest of the highlight stays. That covers a contract contingency period, who pays a closing cost, the loan amount and the down payment. A cancellation the transaction carried on past stays in the summary, marked contradicted by a later document; the highlight names that document. A key date that isn't a date at all, like an escrow number, is left out too. Your own corrections count: change a field and the summary follows it.

A document that doesn't belong here

Some documents aren't part of a home sale's file at all: another kind of deal's contract — a vacant-land, commercial or business purchase agreement, or a lease — or the brokerage's own paperwork, like an independent contractor or referral fee agreement. When one sits beside the home's purchase or listing agreement, the record shows This document may not belong here naming it. Its terms and dates are kept out of the Transaction Record and the deadlines, its people are kept off the Parties (a lease for this property is the exception, below), and it doesn't count as the transaction's purchase agreement on the Files tab. A lease or brokerage paperwork gets the same warning even when it's the only document uploaded. Take it out of the transaction, or move it to the one it belongs to, and the warning clears.

The tenant's own lease is different. When a lease, or other paperwork of a tenancy such as a rental agreement, names this property's address or parcel number as its premises, the record shows The property's current tenancy instead of the warning. It's a note, not an objection: a sale doesn't end a tenancy, so unless it ends before closing the buyer takes the property subject to that lease. Keep it in the file, because the tenant-occupied property addendum (TOPA), the transfer of the tenant's security deposit and any Tenant Protection Act exemption statement rest on it. Looks right clears the note. Its terms and dates still stay out of the Transaction Record and the deadlines, and its row on the Files tab gets no May not belong here tag. If it has already filled in a value on the record, the note says so and asks you to check those fields. A lease whose premises haven't been read, name only a unit, or are another address still gets This document may not belong here.

A lease for this property still tells LetterScript the home is tenant-occupied, so the tenant-occupied steps and notices stay on the timeline. When the lease's premises match this property's address, the tenant and housing providers it names keep their place on the Parties. A lease that hasn't been read yet, doesn't say where its premises are, or names only its unit (such as "Unit B") still counts for the timeline; it adds no one to the Parties, but it removes no one either. A lease whose premises are another address does neither: its people come off the Parties unless another document of this transaction names them, and the record also shows Possible wrong-property document for it.

When the only purchase agreement on the transaction is a vacant-land, commercial or business one, the transaction is treated as that kind of deal and isn't judged by the home-sale checks, so this warning doesn't appear. If that agreement is for a different property, look for Possible wrong-property document instead.

A form that only mentions another one is still read as itself: an addendum that names the purchase agreement it amends is an addendum, and a request for repair that mentions a separate vacant-land contract is a request for repair. In the documents list, each purchase agreement is labeled by its own form, so a Vacant Land Purchase Agreement (VLPA) never reads as an RPA.

Findings about a document

Some flags are about a whole file rather than one value: a document that describes a different property, one that isn't part of a residential sale at all (a vacant-land contract, a lease that isn't this property's current one, brokerage-internal paperwork such as an independent contractor or referral agreement), the current lease of the property being sold, a form missing a signature it needs, a line left blank where it matters, or a numbered chain with a gap (Addendum No. 1 and No. 3, but no No. 2). Each one is a card on the Transaction Record and an item in the transaction's Needs you band, so working through the band covers them all.

A missing signature is judged by who the form says signs it. A cancellation of contract that one side made on its own (paragraph 1A) needs only that side's signature; if it also fills in the deposit instructions, the card says the cancellation stands but the deposit is released only once both sides sign. The buyer's amendment to escrow instructions (BAEI), which only names where escrow sends a demand for the deposit, needs only the buyer's. A demand to close escrow (DCE) needs the signature of whichever side is demanding, and a blank one is flagged under the contract's three-day rule for it (RPA ¶14G), not the two-day rule for notices to perform. A notice or demand is cited to the purchase agreement on file, on its missing-signature card too: paragraph 18 on a new construction contract (NCPA ¶18E, ¶18G), paragraph 16 on a subdivision or condominium conversion contract. An assignment of all of the buyer's interest to the buyer's own trust or wholly-owned entity (paragraph 1E of the assignment form, AOAA) needs only the buyer's signature, because the purchase agreement allows it without the seller's consent; then the new buyer goes on the record. Any other assignment still needs the seller's signature. On a default-sale contract (NODPA), the owner's notice of cancellation is signed only by the owner, and only to cancel: the unsigned copy that goes with the contract isn't flagged.

The two that mean a file may be on the wrong transaction, Wrong property? and May not belong here, also tag that document's row on the Files tab and the top of the document's own page. Hover the tag for the reason. Dismissing the card on the Overview clears it everywhere.

If something looks wrong

A wrong or missing field usually traces back to the documents: the anchoring contract isn't uploaded yet, is still processing, or a newer counter offer hasn't been added. Start with Extraction didn't fill in.

You'll often spot a wrong fact while checking a sheet or letter before it goes out. On that review screen, Also fix it in the transaction record saves a corrected date, contact, escrow number, escrow holder or title company straight to this record, the same as editing it here, so every tab and every later copy follows it; a corrected escrow number, escrow holder or title company carries the note "Corrected while reviewing …", naming the sheet or letter, on its edited mark. See Send and share from a transaction.