← All Posts
November 5, 2026

Real Estate Investment Committee Workflow: Questions for Acquisition Teams

Build a repeatable investment committee workflow with clear deal inputs, review controls, decision records, and practical handoffs for acquisition teams.

Acquisition team reviewing multifamily deal documents around a conference table

A real estate investment committee workflow should help an acquisition team move from an initial opportunity to a documented decision without losing track of evidence, assumptions, or open questions. It does not replace investment judgment. It gives reviewers a consistent way to understand what is being considered, what supports the analysis, and what action the committee is being asked to take.

Call to discuss your team’s workflow

What should the workflow accomplish?

A workable process answers four questions at each stage: What is being considered? What evidence supports the current view? Which assumptions remain uncertain? What decision or next step is needed now? If members cannot locate those answers, adding more slides or software will not fix the underlying process.

Begin with decision stages and ownership. A team could use an initial screen, detailed review, committee discussion, and post-meeting follow-up. Define what must be true to advance a deal, what would stop it, and who can authorize an exception. Avoid sending every opportunity through the same costly level of diligence: a flyer may justify a preliminary screen, while a complete offering memorandum (OM), rent roll, and trailing 12-month operating statement (T-12) may support deeper review.

  • Initial screen: Identify the property, transaction context, known figures, and reason to investigate.
  • Detailed review: Reconcile operating information, document assumptions, and list missing evidence.
  • Committee decision: State the proposed action, material risks, alternatives, and unresolved items.
  • Follow-up: Record conditions, owners, due dates, and the event that would prompt another review.

Label the depth of review. A preliminary view should not be presented as equivalent to diligence on a complete packet. That distinction protects decision quality and helps members understand what an analysis does—and does not—establish.

What belongs in a committee deal packet?

Standardize the packet so members know where to find the narrative and the evidence behind it. The exact contents depend on the transaction and the information available, but important figures should be traceable to a source and missing information should be visible.

  • Opportunity context: Property and market description, transaction status, proposed strategy, and the decision requested.
  • Operating evidence: Seller- or broker-provided OM, rent roll, T-12, and other relevant source files.
  • Underwriting view: Key assumptions, scenario comparisons, relevant comparable information where available, and a clear distinction between source figures and team estimates.
  • Risks and open questions: Items that could change the analysis, each with an owner for follow-up.
  • Decision record: Recommendation, alternatives considered, outcome, conditions, and assigned actions.

Use a consistent file naming and version convention. Include the property, document type, and received or review date. Preserve superseded versions in a way that makes them distinguishable rather than silently replacing them. If a figure changes after the packet is circulated, note the new value, its source, when it changed, and whether the change affects the recommendation.

A concise cover page can orient readers, but it should not hide uncertainty. Mark each important number as a source figure, team adjustment, or open assumption. If the seller’s rent roll and the team’s model use different unit classifications, call out the difference instead of smoothing it away in a summary.

How should underwriting be reviewed?

Make review a defined step, not a glance at the final output. Reconcile key figures with original source documents. Confirm that documents cover the correct property and period, and check classifications, unit mix, and units of measure. Flag discrepancies that cannot be resolved from the packet.

When information is extracted from a document, compare it with the source, especially when the file is scanned or handwritten. A value can be misread or assigned to the wrong category. Correct the input, then verify that the correction flows through the assumptions and model as expected. AI-generated evaluations can be inaccurate and are not professional financial, tax, investment, or accounting advice. The team remains responsible for checking source material and applying its judgment.

Separate what is known from what is assumed. For example, a packet might state that a rent figure comes from a supplied rent roll, while a vacancy adjustment is a team assumption that requires review. For major drivers, show a base case and a relevant alternative. Explain what changed and why it matters; avoid implying that one modeled outcome is inevitable.

A practical review sequence is:

  1. Confirm property identity, reporting period, and document version.
  2. Trace material inputs to the source file and note page, row, or schedule where possible.
  3. Check classifications, unit mix, formulas, and any manual adjustments.
  4. Compare the base case with a meaningful alternative and identify the main sensitivities.
  5. Record unresolved evidence and the owner responsible for resolving it.

This sequence does not dictate a particular underwriting conclusion. It makes the reasoning easier to inspect and gives committee members a focused way to challenge inputs or assumptions.

Which controls make the process repeatable?

Controls should reduce avoidable confusion while leaving room for informed judgment. Assign roles for preparation, independent review, approval, and distribution. The preparer should not be the only person checking material inputs. Set a packet cutoff, and maintain a visible change log for late updates.

Control Risk it addresses Practical check
Source references Figures that cannot be verified Can a reviewer locate the source file and relevant page or row?
Version labels Conflicting packet copies Is the current version clear, with prior versions retained appropriately?
Assumption labels Facts and estimates being confused Can members tell reported figures from team adjustments?
Independent review Input or classification errors Has another reviewer checked material figures against source material?
Decision log Unclear outcome and ownership Are outcome, conditions, owner, and due date recorded?

Define where the authoritative packet lives. If the team uses email, a shared drive, a CRM, or a deal room, specify which location contains the current approved materials and how updates are communicated. Set access according to the deal and the people involved: who may see source files, edit the model, and distribute committee materials?

A written charter or work plan can clarify committee responsibilities and recurring tasks. For a general example of how an investment committee work plan can describe responsibilities, see the Pennsylvania Public School Employees’ Retirement System Investment Committee Work Plan. It is an institutional example, not a rule for private real-estate committees; teams should adapt governance to their own authority and obligations.

How should the packet support the meeting?

Put the decision request near the beginning. Members should not have to infer whether the team seeks permission to continue diligence, approval to proceed, a revised analysis, or another action. Summarize the recommendation, principal drivers, downside considerations, and unresolved questions. Keep detailed schedules available and make the route from summary to source clear.

Structure discussion around decisions and exceptions rather than reading every document line by line. For each opportunity, identify what changed since the last review, what evidence is new, and where member attention is needed. A concise agenda can reserve time for the decision, key assumptions, downside and alternatives, and conditions. Record dissent or conditions accurately enough for the team to act on them later.

  1. Confirm the decision requested and the version under discussion.
  2. Review material changes, key assumptions, and unresolved evidence.
  3. Discuss risks, alternatives, and conditions to proceeding.
  4. State the outcome and capture follow-up owners and due dates.

If new information arrives during the meeting, distinguish it from the packet’s reviewed evidence. Decide whether it is sufficient for a decision or whether the item should be deferred pending verification. That small pause can prevent an unreviewed update from being treated as an established input.

What should happen after the decision?

Close the loop while the discussion is fresh. Record whether the committee approved, declined, deferred, or requested revisions. Note conditions and distinguish them from informal discussion. Assign each action to an owner and due date, and say whether completing it requires another committee review or another approval.

A useful decision log includes the opportunity, meeting date, materials version, requested action, outcome, conditions, unresolved questions, action owners, and due dates. For a deferral, state what information is missing and what threshold would make the item ready to return. For a conditional approval, state who verifies each condition and when.

Use the record to improve the next review. If the committee repeatedly asks for the same missing information, add it to the packet standard. If a specific assumption is frequently disputed, clarify its source or document how the team sets it. Review process friction separately from investment outcomes: a smooth workflow does not establish that a deal was a good investment.

How can a team compare workflow tools?

First identify the bottleneck. Is the team spending time organizing documents, reconciling deal figures, preparing an editable model, distributing packets, or tracking decisions? A tool that addresses one step may not manage the entire committee process. Write down what needs to be faster or more consistent, and what must remain under human review.

Test options using the same representative workflow, not just a polished demonstration. Use a packet with an incomplete document, a source figure that needs correction, a changed assumption, and a reviewer handoff. Check whether users can locate the evidence, correct the input, understand the output, and preserve the decision record. Ask who owns the review and where approved materials will live.

Evaluation area Questions to test Evidence to request
Document intake Which source files can the workflow accept, and how are gaps shown? A test using representative flyer, OM, rent roll, or T-12 material
Reviewability Can a reviewer trace and correct an extracted figure? Source-to-output comparison and correction path
Assumptions Can users change assumptions and see what changed? Editable output and a documented scenario comparison
Committee handoff How are approved versions and decisions recorded? A sample handoff and clear location for the decision log
Scope and access Who can use, edit, or receive the result? Current plan terms or written project scope

Slung has two distinct paths. For multifamily underwriting evaluation, its documented workflow starts with deal documents such as a flyer, OM, rent roll, or T-12; users review extracted figures, adjust assumptions, and receive a portable, editable Excel model. A one-page flyer is a starting point, not a substitute for checking source documents. Review current product information at Slung’s website, and confirm plan-specific access and terms directly.

For a broader internal process—such as reporting, CRM updates, or another proprietary workflow—the Enterprise path begins with discovery and scoping. Slung describes work as Imagine, Build, and Evolve: explore the challenge, build and test on actual client deals, documents, and processes with team participation, then consider later improvements. Scope, support, ownership, access, and handoff depend on the agreement; examples are not a standard package or promise of results. Learn about Slung Enterprise implementation or use the contact page to discuss a scoped workflow.

When comparing a product evaluation with an implementation engagement, keep the buying job clear. A product test asks whether a defined underwriting task fits the software and whether a reviewer can validate its output. A scoped implementation asks whether a team process can be built and tested against agreed materials and whether the team can operate the resulting workflow. Neither removes the need to agree on roles, review controls, and decision authority.

Before a pilot, write a short acceptance checklist. For example, require that a reviewer can identify the source of a material input, correct an error without losing the change history, distinguish supplied data from team assumptions, and export or circulate the approved version in the format the committee uses. Include an incomplete-file case, not only a clean sample. Agree who supplies test documents, who evaluates the result, and what happens to unresolved exceptions. These checks make a tool comparison specific to the committee’s real work instead of to a feature list.

Also decide how the workflow fits existing responsibilities. A system may help organize extraction or reporting, but the team still needs a person accountable for confirming source information and a committee with clear authority to make the decision. Ask whether the output is editable, how corrections are made, how users know which version is current, and what access different participants receive. For an implementation, clarify scope and handoff in writing. For a software plan, verify current feature and access terms rather than assuming that every feature is included.

FAQ: questions acquisition teams ask

What is the difference between an investment committee workflow and an underwriting model?

The model supports analysis of a deal’s operating information and assumptions. The committee workflow also governs how an opportunity is screened, reviewed, discussed, decided, and followed up. The model can inform the decision, but it does not set approval authority or create the decision record by itself.

How often should a deal packet be updated?

Update it when material information changes and before a decision meeting, using a clear version label and change note. Set a cutoff that gives reviewers time to inspect late changes. The appropriate cadence depends on the transaction and the team’s decision schedule.

Can extracted figures be used without checking the source?

No. Check extracted values against original documents, especially scans, handwriting, classifications, and unit mix. Correct errors before relying on the analysis, and retain a record of material adjustments.

What should a committee decision log contain?

Record the opportunity, meeting date, materials version, requested action, outcome, conditions, unresolved questions, action owners, and due dates. Include enough context to distinguish a deferral or revision request from approval.

Tell us about your team’s workflow

A strong workflow makes evidence, assumptions, decisions, and responsibilities visible from the first screen through follow-up. Review the process periodically so it remains useful as the team’s deals, documents, and information needs change.

Slung logo

Subscribe

Subscribe to our newsletter for exclusive updates, insider tips, and offers delivered straight to your inbox.