CRM MVP
The date the opportunity was settled, recorded when it closes.
Usually stamped by the platform at close. It is not the expected close date and must never be scored from it. Where one field serves both purposes, establish what the field holds after close.
No sales cycle length, so you cannot say how long a sale takes or whether it is getting longer, which is the number that tells you whether a process change worked. No way to report what closed in a given period, which is what commission runs and revenue recognition depend on.
In full where a close date is recorded at close, whether stamped by the platform or entered by a person into a shipped field. In part where the buyer must create the field. Not at all where the date a sale ended is not kept.
The opportunity carries an Open date and a Close date as shipped fields, both distinct from the Est. Close Date that is set when the opportunity is created and can be revised while it is live. The documented closing procedure asks only for a Status value and an optional Reason - no date is typed - and a closed opportunity cannot be edited. Reversing the transition is described as system-driven: on reopening, the Open Date is changed to the current date and the Close Date is changed to None. Act! therefore manages the Close Date itself at the status change. The help text does not use the word automatic for the closing direction, so the auto reading rests on the absence of any date input in the close dialog plus the documented automatic reset on reopen.
The vendor ships a separate Actual Close Date, exposed in the API as closedOn and described as the date the opportunity was closed. The support documentation states that once the opportunity is won or lost, Capsule fills this field in to show when it closed, and contrasts it with the Expected Close Date a user enters, so the two can be compared. It does not appear in the documented create or update request bodies.
Actual Close Date is a shipped opportunity field, separate from Forecast Close Date, which holds the estimated date. Insightly documents it as being updated by the system when the state is changed, warning that choosing Suspended rather than Won stops Actual Close Date being updated on the opportunity. Both dates are listed as importable and both are tracked as changed fields in the Opportunity History Report.
close_time is documented as the date and time the deal was closed and can only hold a value once the status is won or lost, and it is separate from expected_close_date. won_time is described as the moment the status changed to won. The knowledge base treats won time as something already present after a deal is marked won, describing how to correct it if a deal was marked won prematurely, which is an admin-only edit.
ActiveCampaign keeps the settlement date itself, distinct from the shipped Forecasted Close Date that a user sets. The Forecasted Close Date article draws the line directly, describing that field as separate from the opportunity's native data such as the created date or the date on which the status was changed to won or lost. The Deal Forecast report then scores forecast accuracy by comparing the forecasted date against the date the opportunity was actually marked won, and the Deal Overview report reports an average time to won. No user is asked to type a settlement date - it follows from the status change - so the platform stamps it. Worth noting for the buyer: this date is surfaced through reporting rather than as a plainly named close-date attribute in the deal API schema.
The opportunity ships date_won and date_lost attributes, separate from the Estimated Close date a user sets. The API reference states that date_won is filled in with the current date automatically when the status is changed to one typed won, unless a value was supplied, and that reverting the status later does not clear it. The equivalent automatic behaviour for date_lost is not described.
Keap's help centre documents an estimated close date added when the deal is created, but no vendor documentation found states that a second field records the date the deal was actually settled, nor that anything is stamped when the Status is set to Won or Lost. A Keap product announcement mentions filtering pipeline analytics by date closed, but a product announcement is not product documentation and cannot support this on its own.
Every vendor page that enumerates opportunity dates names only Estimated Close. The record walkthrough lists Description, Sales Person, Type, Pipeline, Size, Margin, Summary, Analysis, Current Status, Source and Guttometer with no settled date; the filtering guide gives Estimated Close as the opportunity date filter; the Kanban page offers editing the estimated close date and a Kanban by Estimated Close view; and the standard sales reports reference order date, estimated close date and last ordered, never a date an opportunity was closed. The Sales Rep dashboard reports opportunities closed this month, last month and in the last ninety days but the vendor does not say what date drives that.
Copper ships one close_date field, documented in the API reference as the expected close date, and there is no second field for the date an opportunity actually settled. The vendor's help centre instructs the user to set that same field when closing: to add a closing date showing when the deal was completed on a win, and to change the close date to today on a loss. No vendor documentation states that Copper stamps the date itself when status changes.
The shipped Close Date attribute is documented as an estimated close date picked from a calendar, which is the expected date rather than the settlement date. Apptivo's own support answer on making that date reflect reality tells the customer to build an event-based trigger in Opportunities settings that fires on update, tests whether the sales stage equals Closed Won or Closed Lost, and then uses an Update Attribute action to set Close Date to the Now system variable. The date an opportunity actually settled is therefore only captured if the buyer configures that automation.
The opportunity table ships actualclosedate, described as showing when the opportunity was closed or cancelled, alongside the separate estimatedclosedate used for forecasting. Closing the opportunity automatically creates an Opportunity Close activity record holding the close date and actual revenue. The close dialog presents the close date for the user to verify and adjust, so the stamped value can be overridden.
Salesforce ships one Close Date field, documented as the date you plan to close the opportunity, and no separate field for the date it actually settled. The vendor also documents that moving an open opportunity to a stage of type Closed/Won rewrites Close Date to the current date in UTC when the stored value was in the future, and leaves it untouched when the stored value was already in the past. The shipped field is therefore stamped by the platform at close rather than left purely as a forecast, and the documented stamping behaviour is described for the Closed/Won stage type.
No date attribute of any kind ships on the standard Deals object, so neither the expected nor the settled date is a vendor-supplied field. Attio's own reporting help refers to grouping an Insight report by a custom date attribute such as a Close date attribute, which places the field on the buyer to create and populate. Attio does stamp an active_from timestamp on the status value when a record sits in a stage, and Stage changed reports count records entering a stage in a window, but the documentation does not present that as a close date field on the opportunity and does not define active_from's meaning in the record reference.
folk's help centre states that the default deal template supplies pre-made custom fields including Closed at, so a date field for when a deal ended arrives without the buyer building it. It is an ordinary custom date field though: the API reference shows no native close date on the deal, folk documents no close action, and nothing in the documentation says the platform writes the value, so a person enters it.
The only date column shipped on the Deals board is Expected Close Date, and the Forecasting View's own close date mapping is documented as the expected close date for each deal. No vendor documentation describes a field holding the date an opportunity was actually settled, so a buyer wanting one must add a date column of their own to the board.
The only date of that kind in the module is Closing date, which the vendor defines as the expected closing date of the pipeline record, and which sits alongside Amount as the amount expected after closing. The published list of default fields for the Pipelines module contains no second date for when the record was actually settled, and the module's API response returns only Closing_Date, Created_Time, Modified_Time and Last_Activity_Time. The record's Timeline tab holds a history of what was done to the record, but that is an audit trail rather than a field.
No date column ships in a pipeline. Streak's own projected close value report is documented as reading close dates from an expected close date column the buyer adds, and the magic column families on offer cover activity metadata such as the last stage change, email counts and task progress rather than a settled date. Anything holding the date a sale ended has to be created by the buyer.
Nimble ships an Actual close date on the deal, listed by the vendor as a sort option alongside Expected close date, so the two are distinct fields. It is a human entry rather than a stamp: the vendor states that when a deal is dropped into Won or Lost the user is prompted to supply the amount, the close date and notes. Nothing in the documentation says Nimble fills the date itself.
Freshsales ships two separate date fields on the deal: Expected close date, described as when the deal is expected to close, and Closed date, described as when the deal is closed. Closed date is listed among the Basic Information fields, which the vendor says can be filled in manually through deal forms and during import. No vendor documentation states that Freshsales writes the value itself when a deal reaches the Won or Lost stage, so this is recorded as a shipped field a person fills.
Expected Close Date ships on the deal and Vtiger uses it by name in its own workflow examples. No vendor page reviewed describes a field holding the date a deal actually ended, and the vendor's own closing instruction covers only the Sales Stage change with no mention of a date being stamped. This could not be settled either way because the knowledge base pages that would enumerate the module's shipped fields returned navigation only.
No vendor documentation was found that either names a field holding the date an opportunity was settled or states that none exists. The pipeline analytics page reports revenue over time and counts of created, won and lost opportunities, but does not say which date those measures are keyed to.
Nutshell keeps an actual close date distinct from the expected one: the custom report documentation states the closed date filter spans both actual and expected close dates, the sales report plots won leads along an axis that is the close date, and Closed Time is a mappable field on import alongside Open Time. The in-app close is documented purely as a status change with no date entry, so the value comes from the platform rather than the user; the only place the vendor documents a person supplying it is an import of historical sales.
HubSpot ships a single Close date property described as the day the deal is expected to close or was closed, so one field serves both purposes rather than the settled date living in its own field. The vendor documents that moving a record into a closed stage updates Close date to today's date by default, which is the automatic stamp; the same article notes the behaviour can be switched off per pipeline.
Closing Date ships as a mandatory Deals field and Zoho documents it as the expected close date. No second field records the date the deal actually ended. Instead, selecting a stage marked closed won or closed lost raises a Verify Details window that the user must complete to close the deal, presenting the amount, closing date and stage, so the settled date is whatever the person enters or leaves in place.